Is this project dead?

[Zerokami]

The Latest commit was on 20 Dec 2013. That's clearly very old. I'm not sure if it works.

Does this still work? Is this project dead? What are the alternatives?

[mojotoad]

I sure hope it's not abandoned. It's a great piece of software.

Matt
On Dec 30, 2015 7:17 AM, "Logmytech" notifications@github.com wrote:

The Latest commit was on 20 Dec 2013 That's clearly very old I'm not sure
if it works

Does this still work? Is this project dead? What are the alternatives?

—
Reply to this email directly or view it on GitHub
#91.

[jjegg]

Nope, it all still works!

[R-eyes]

What are the alternatives?
This project is different, but it might interest you as well: https://github.com/threatstream/mhn

[mileswdavis]

I would have to agree with the commentary of dead. Last commit in 2013 (now 2 years ago) and no commentary from the owners. I have had major issues after compiling this on Trusty Tahr, Ubuntu has stopped including it in it's repos, and Kali, the most popular security suite, doesn't bother to include it either. I have been considering taking it over but I am not sure how much interest there is. Lot's of other honeypot tools exist today with seemingly much better tooling but none that try to do what honeyd does. Is anyone else out there in the same boat as I am (would love to see this project revitalized but not quite sure if there is enough value).

[awaldow]

Note: I no longer work at DataSoft, so I am not sure what is going on
internally over there anymore regarding work on honeyd.

honeyd was used by DataSoft with the express purpose of integrating it with
the NOVA product that they offer. It looks dead because we weren't really
adding anything to it, just leveraging the capabilities it provides in
conjunction with NOVA and it's UI. After a point we had other internal
priorities regarding its use so we decided it was feature complete for what
we were using it for and didn't touch it again. I'm sure there's a lot of
work and interesting capability that could be added but to be honest aside
from some quirks Provos did a great job the first time and there wasn't
really much to do in the way of bug fixing that affected our business
needs. The most that honeyd really needed from us was some adjustment of
the script structure and updating some of the personality stuff to keep up
with nmap development (since honeyd uses nmap's fingerprinting statistics
to emulate the various OS personalities). If there's something that you
really need/want out of it I would suggest speaking with the people over at
DataSoft and see what they say. That being said, this is an open source
repo so if you really want new features you could always toss your hat in
the ring and make a pull request.

On Tue, Jan 26, 2016 at 9:50 AM, Miles Davis notifications@github.com
wrote:

I would have to agree with the commentary of dead. Last commit in 2013
(now 2 years ago) and no commentary from the owners. I have had major
issues after compiling this on Trusty Tahr, Ubuntu has stopped including it
in it's repos, and Kali, the most popular security suite, doesn't bother to
include it either. I have been considering taking it over but I am not sure
how much interest there is. Lot's of other honeypot tools exist today with
seemingly much better tooling but none that try to do what honeyd does. Is
anyone else out there in the same boat as I am (would love to see this
project revitalized but not quite sure if there is enough value).

—
Reply to this email directly or view it on GitHub
#91 (comment).

[mileswdavis]

Thanks Addison. That definitely clears up the why it has been untouched for a while.

I think there is some functionality that could be added but to be honest that wasn't my first priority. The bigger concern is what I see as defects that have crept in likely with changes that have occurred in packages it relies on.

If I rely on older releases (1.5c), all seems to work without issue. I specifically tried this out with HoneyDrive (a distro that combines a multitude of Honeypot tools). I was successful with 1.5c but the problem was all the fingerprints were basically worthless since they were out of date. After upgrading from source here (denoted 1.6d), my emulated clients can't even get DHCP. Without anyone looking at the project I doubt any progress would be made if I file an issue.

I think that Pulling is probably the option I will go with but I wanted to see if I could

1. Inspire the original authors to give their view (Thank you!)
2. Gauge interest in the project to measure the value vs. time investment
3. Gather interested parties to help with a branch
4. See if someone knew of a tool that has replaced honeyd in terms of functionality (low touch, fingerprint aware, and flexible)

[awaldow]

I will say that getting honeyd to work in later versions of Ubuntu could be occurring internally at DataSoft, when I left we were trying to make NOVA more portable as we were using libboost before the backwards compatibility breaking change they made in 1.52 (I think, I honestly can't remember pffhand). However, and take this as you will, the build target for NOVA was strictly 12.04 and temporally concurrent releases of other distros due to library versioning stuff  and I'm not sure what sort of progress they've made in that arena. Again, I can't speak on their behalf anymore as I've taken another employment opportunity. You could email the Nova support account as honeyd work falls under that implicitly.

On Jan 26, 2016, 11:22, at 11:22, Miles Davis notifications@github.com wrote:

Thanks Addison. That definitely clears up the why it has been untouched
for a while.

I think there is some functionality that could be added but to be
honest that wasn't my first priority. The bigger concern is what I see
as defects that have crept in likely with changes that have occurred in
packages it relies on.

If I rely on older releases (1.5c), all seems to work without issue. I
specifically tried this out with HoneyDrive (a distro that combines a
multitude of Honeypot tools). I was successful with 1.5c but the
problem was all the fingerprints were basically worthless since they
were out of date. After upgrading from source here (denoted 1.6d), my
emulated clients can't even get DHCP. Without anyone looking at the
project I doubt any progress would be made if I file an issue.

I think that Pulling is probably the option I will go with but I wanted
to see if I could

1. Inspire the original authors to give their view (Thank you!)
2. Gauge interest in the project to measure the value vs. time
   investment
3. Gather interested parties to help with a branch
4. See if someone knew of a tool that has replaced honeyd in terms of
   functionality (low touch, fingerprint aware, and flexible)

---

Reply to this email directly or view it on GitHub:
#91 (comment)

[aleno]

The fingerprint definition files comes from nmap. Unless they recently changed the format you could try replacing nmap-os-prefixes and nmap-os-db with the ones from https://github.com/nmap/nmap

[awaldow]

Yup. That's how we did it when I was there.

On Thu, Jan 28, 2016 at 7:03 AM, Alexander Norström <
notifications@github.com> wrote:

The fingerprint definition files comes from nmap. Unless they recently
changed the format you could try replacing nmap-os-prefixes and nmap-os-db
with the ones from https://github.com/nmap/nmap

—
Reply to this email directly or view it on GitHub
#91 (comment).

[mileswdavis]

Maybe I don't have a good enough understanding of nmap fingerprints and their interaction with honeyd, but honeyd 1.5c used a called nmap.prints for it's fingerprints. That file format is much different than the current nmap-os-db file format that nmap uses today. Now, nmap 1.6d has seeming converted over to using the new nmap-os-db format (and the nmap-os-prefixes), but that circles me back to my original problem of seeming incompatibilities with modern distros.

I was able to do exactly what you stated (pull over nmap-os-db into honeyd) and have the honeyd config file I was running parse correctly using new fingerprints, but, again, since it didn't work it didn't really matter.

[awaldow]

Is your honeyd on a vm?

On Jan 28, 2016, 09:45, at 09:45, Miles Davis notifications@github.com wrote:

Maybe I don't have a good enough understanding of nmap fingerprints and
their interaction with honeyd, but honeyd 1.5c used a called
nmap.prints for it's fingerprints. That file format is much different
than the current nmap-os-db file format that nmap uses today. Now, nmap
1.6d has seeming converted over to using the new nmap-os-db format (and
the nmap-os-prefixes), but that circles me back to my original problem
of seeming incompatibilities with modern distros.

I was able to do exactly what you stated (pull over nmap-os-db into
honeyd) and have the honeyd config file I was running parse correctly
using new fingerprints, but, again, since it didn't work it didn't
really matter.

---

Reply to this email directly or view it on GitHub:
#91 (comment)

[mileswdavis]

That is a foreboding question :). Yes. I have been testing on a VM. Since 1.5 worked without flaw and I upgraded the same machine to 1.6, I thought I had eliminated virtualization as a roadblock. I guess I will find out!

[awaldow]

Well, I can give a little background to why I ask that question after I get
out of a meeting I have right now. But whether that explanation is relevant
will depend on whether your VM interface is set to promiscuous mode or not.
Would you mind describing the problem that you're having a little more so I
can think of what it might be? You're just not having nodes get allocated a
DHCP address right?

On Thu, Jan 28, 2016 at 9:54 AM, Miles Davis notifications@github.com
wrote:

That is a foreboding question :). Yes. I have been testing on a VM. Since
1.5 worked without flaw and I upgraded the same machine to 1.6, I thought I
had eliminated virtualization as a roadblock. I guess I will find out!

—
Reply to this email directly or view it on GitHub
#91 (comment).

[mileswdavis]

Ah. We are on the same page then.

I don't want to get this thread too off topic; I can always open another issue purposed at the DHCP issue if I thought someone was actively developing.

Just to close this out (hopefully): Interfaces are set in promiscuous mode. I can confirm that is the case because the honeyd configuration file that I used going from 1.5 to 1.6 was exactly the same apart from the fingerprint names. VM started the same, hypervisor stayed the same, all other variables static except honeyd version.

Thanks for the willingness to help through. If we want to continue debugging I will recreate the scenario, take more notes, and open a new issue to try to figure out what is going on.