Dionaea with p0f

Working my way through the compilation instructions from Dionaea whilst building up my latest sensor I was reminded of some optional functionality that I’d always intended to implement, but never found the time. First on my list was p0f (that’s a zero).
From p0f’s homepage:

P0f v2 is a versatile passive OS fingerprinting tool. P0f can identify the operating system on:
– machines that connect to your box (SYN mode),
– machines you connect to (SYN+ACK mode),
– machine you cannot connect to (RST+ mode),
– machines whose communications you can observe.
P0f can also do many other tricks, and can detect or measure the following:
– firewall presence, NAT use (useful for policy enforcement),
– existence of a load balancer setup,
– the distance to the remote system and its uptime,
– other guy’s network hookup (DSL, OC3, avian carriers) and his ISP.

Setting p0f up on the sensor should have been straightforward;

  • Install with: apt-get install p0f
  • Run p0f as suggested in dionaea.conf: sudo p0f -i any -u root -Q /tmp/p0f.sock -q -l
  • And edit dionaea.conf’s ihandler section to enable p0f

This mostly worked, watching the p0f output it was correctly (I’m assuming) providing stats about connecting systems. The problem was that p0f info wasn’t getting saved into Dionaea’s logsqlite database, dionaea-error.log was reporting the below error with each connection:

[04122010 13:48:44] connection connection.c:827-warning: Could not connect un:///tmp/p0f.sock:0 (Permission denied)

Which seemed odd, /tmp/p0f.sock was showing as globally readable. Re-reading the Dionaea compilation instructions I noticed a comment about p0f struggling with IPv6 so has problems it Dionaea is listening on ::, which mine was. Problem solved, I edited dionaea.conf so that Listen mode was set to “manual”, and provided the interface/IP details of my network connection. Only this didn’t solve my problem…
Head thoroughly hurting I swallowed my ego and asked for assistance on the mailing list, and promptly (thanks again Ryan) got a reply that provided a functional workaround.
So, why go to the effort? Main purpose behind running honeypot systems (for me) is to get a better idea understanding of what threats are actively targeting systems in the wild. At first glance the information provided by p0f can quickly help evaluate the attacking system; what OS? what connection type? is it local?
With the limited (few hours) of data I’ve already collected heres a sample of the info you can gather:
last 5 connections:

p0f connection p0f_genre p0f_link p0f_detail p0f_uptime p0f_tos p0f_dist p0f_nat p0f_fw
328 822 Windows IPv6/IPIP 2000 SP4, XP SP1+ -1 17 0 0
327 821 Windows IPv6/IPIP 2000 SP4, XP SP1+ -1 17 0 0
326 820 Windows 2000 SP4, XP SP1+ -1 14 0 0
325 819 Windows 2000 SP4, XP SP1+ -1 14 0 0
324 818 Linux pppoe (DSL) 2.4-2.6 5 13 0 0

SQL Query:

select *
from p0fs
order by
connection desc
limit 5;

Breakdown by OS

count OS
324 Windows
17 Linux

SQL Query:

select count(p0f_genre) as count, p0f_genre as OS
from p0fs
group by p0f_genre
order by count(p0f_genre) desc;

Umm, so most systems spreading malware are (likely) infected Windows systems. No great surprise there…
Connectivity Types

Count Connectivity
153 IPv6/IPIP
149 ethernet/modem
40 pppoe (DSL)
12 (Google/AOL)
5 GPRS, T1, FreeS/WAN
3 PIX, SMC, sometimes wireless
2 sometimes DSL (2)
2 sometimes DSL (4)

SQL Query:

select count(p0f_link), p0f_link
from p0fs
group by p0f_link
order by count(p0f_link) desc;

Unfortunately the the information provided by p0f isn’t an exact science, and as devices and systems are constantly changing it’s only going to be as accurate as it’s latest signatures/fingerprints. But setup is fairly quick, and the information and insight provided fairly interesting. So why not give it a go?
–Andrew Waite

Join the conversation


  1. the unix domain socket has to be *writeable* for the dionaea user too, readable is not enough

    1. Thanks Markus, that explains where I was going wrong. I’d assumed Dionaea just consumed data as it was pushed out the socket.
      (yep, know assumption is the mother of all……)

  2. p0fd uses a unix domain socket to communicate, you need to be allowed to write the ‘file’ before you can even connect() it.
    p0f works with queries, you query the daemon for information you are interested in.
    For large deployments increasing the p0fd cache improves results.

  3. hi, Andrew, i am new in seting honeypot. I have tried to using Nepenthes for 2 weeks, but it is weird that I can not get the binaries files and only get info in nepenthes.log file like below:

    Socket tcp (accept) 70.84.*:3285 ->192.168.*:143 clearing DialogueList(1 entries)

    [16:17:50 warn module] Unknown WatchDialogue 0 bytes,port 110

    [16:17:50 warn module] Unknown exploit 0 bytes

    [16:17:50 warn module] Unknown VERITAS explot 0 bytes State 0

    I think because the “0 bytes”, so I can not get the binaries files. But I do not kown why always “0 bytes”
    with the warn module.
    Now I am trying to use Dionaea, and follow the install guide in
    I do not use “surfids”, so I just drop all the part with “surfids”.
    Everything is fine till I use the starting command:
    /opt/dionaea/bin/dionaea -l warning -L ‘*’ -p /var/run/dionaea.pid
    And get the info below:
    Dionaea Version 0.1.0
    Compiled on Linux/x86_64 at Dec 11 2010 with gcc 4.4.3
    Started on * running Linux/x86_64 release 2.6.32-21-server
    I have checked that there is no dionaea.pid file I do not know how this happens and find no info about this by google, do you have any idea?

    1. I’ve not used the SurfIDS instructions before (not currently using it), but I think I remember a comment on the mailing list with a similar issue, and Markus stated that the SurfIDS instructions were outdated (sorry, can’t find source, could be wrong). Either way, if you not using SurfIDS (or even if you were) I’d recommend using the ‘official’ Dionaea compilation instructions: http://dionaea.carnivore.it/#compiling.
      Hopefully you can just skip to the end, trying running with the examples from the onboard help:

      # dionaea -l all,-debug -L ‘*’
      # dionaea -l all,-debug -L ‘con*,py*’
      # dionaea -u nobody -g nogroup -r /opt/dionaea/ -w /opt/dionaea -p /opt/dionaea/var/dionaea.pid

      Any luck? If not, my usual problem on a fresh build is I’ve missed some permissions along the way, (re)read the compilation/installation instructions above and check every file/folder is set correctly.
      Hope this helps,

  4. I too have the same issue with p0f, can you tell me what the work aound was please?
    As the link is dead to Ryans reply 🙁
    Loving the dinaea.
    Thanks in advance

    1. Hi Dave,
      not sure why the mailing list link has stopped functioning, Ryan’s reply is now at http://sourceforge.net/mailarchive/message.php?msg_id=26699222 (I’ll update link in post also). In case it changes again, Ryan’s response was:
      I had some weird problems with permissions with p0f. In the end, I
      just set p0f to run as the same user as the dionaea process. Here are
      all my settings/command lines:
      sudo p0f -i any -u dionaea -Q /opt/dionaea/tmp/p0f.sock -q -l -d -o /var/log/p0f.log
      srwxr-xr-x 1 dionaea dionaea 0 2010-10-24 14:46 /opt/dionaea/tmp/p0f.sock
      sudo /opt/dionaea/bin/dionaea -u dionaea -g dionaea -l all,-debug -L ‘*’ -p /opt/dionaea/var/run/dionaea.pid
      p0f = {
      * start p0f with
      * sudo p0f -i any -u root -Q /tmp/p0f.sock -q -l
      path = “un:///opt/dionaea/tmp/p0f.sock”
      Hope this helps Dave, and thanks again Ryan 🙂

  5. Hello Andrew. Does p0f has any seperate DB logging options? Or are these queries supposed to be run against Dionaea’s SQLite database? I’ve just started using Dionaea again and your posts are useful as always 🙂

    1. As I had it setup, Dionaea logged the p0f findings to it’s own database, and it’s the Dionaea database that the queries above are designed for.
      Although since I set this up a new version of p0f has been released and I’m behind in keeping Dionaea up to date (new sensor currently a work in progress) so your mileage may vary depending on your exact versions and backwards compatibility issues.

  6. I have installed p0f and I am running it, however, I do not know what I am looking at.
    10.0.X.X:59520 – UNKNOWN: [S10:64:1:60:M1460,S,T,N,W7:.:?:?] (UP: 106 hrs) -> 91.X.X.X:443 (link: ethernet/modem)

    1. Hi Jeremy,
      apologises for delay to get to this one, busy few days 🙁
      Easiest way I’ve found to interpret the p0f findings is to rely on Dionaea’ sqlite database (see response to other post for troubleshooting if needed). Makes it easy to match IPs to OS versions, grab stats and trends etc.

Leave a comment

Your email address will not be published. Required fields are marked *