<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Honeypots</title>
    <link>http://seclists.org/#honeypots</link>
    <atom:link href="http://seclists.org/rss/honeypots.rss" rel="self" type="application/rss+xml" />
    <language>en-us</language>
    <description>Discussions about tracking attackers by setting up decoy honeypots or entire &lt;A HREF=&quot;http://www.honeynet.org&quot;&gt;honeynet&lt;/A&gt; networks.</description>
    <pubDate>Wed, 03 Mar 2010 15:45:26 GMT</pubDate>
    <lastBuildDate>Wed, 03 Mar 2010 15:45:26 GMT</lastBuildDate>
<!-- MHonArc v2.6.16 -->

 

  <item>
    <title>Re: DNS honeypots?</title>
    <link>http://seclists.org/honeypots/2010/q1/13</link>
    <description>&lt;p&gt;Posted by Jason Ross on Mar 03&lt;/p&gt;But it would have the advantage of allowing you to capture further&lt;br&gt;
traffic for analysis through whatever tools you choose.&lt;br&gt;</description>
    <pubDate>Wed, 03 Mar 2010 15:32:42 GMT</pubDate>
    <guid isPermaLink="true">http://seclists.org/honeypots/2010/q1/13</guid>
  </item>
  <item>
    <title>Re: DNS honeypots?</title>
    <link>http://seclists.org/honeypots/2010/q1/12</link>
    <description>&lt;p&gt;Posted by Alexandre Dulaunoy on Mar 03&lt;/p&gt;We have used various techniques to make DNS honeypots. But there is&lt;br&gt;
an easy to do &amp;quot;fake&amp;quot; DNS server using Net::DNS::Nameserver :&lt;br&gt;
&lt;br&gt;
&lt;a  rel=&quot;nofollow&quot; href=&quot;http://search.cpan.org/~olaf/Net-DNS/&quot;&gt;http://search.cpan.org/~olaf/Net-DNS/&lt;/a&gt;&lt;br&gt;
&lt;br&gt;
You can even find a simple example in the POD :&lt;br&gt;
&lt;br&gt;
&lt;a  rel=&quot;nofollow&quot; href=&quot;http://search.cpan.org/~olaf/Net-DNS/lib/Net/DNS/Nameserver.pm&quot;&gt;http://search.cpan.org/~olaf/Net-DNS/lib/Net/DNS/Nameserver.pm&lt;/a&gt;&lt;br&gt;
&lt;br&gt;
If you want to make a low-interaction nameserver, you can filter&lt;br&gt;
the request and answer to limit the malicious queries but still gain&lt;br&gt;
information by doing and...&lt;br&gt;</description>
    <pubDate>Wed, 03 Mar 2010 15:27:05 GMT</pubDate>
    <guid isPermaLink="true">http://seclists.org/honeypots/2010/q1/12</guid>
  </item>
  <item>
    <title>Re: DNS honeypots?</title>
    <link>http://seclists.org/honeypots/2010/q1/11</link>
    <description>&lt;p&gt;Posted by Brent Huston on Mar 03&lt;/p&gt;Likely nothing today, most malware isn't smart enough to figure that out.&lt;br&gt;</description>
    <pubDate>Wed, 03 Mar 2010 15:00:23 GMT</pubDate>
    <guid isPermaLink="true">http://seclists.org/honeypots/2010/q1/11</guid>
  </item>
  <item>
    <title>Re: DNS honeypots?</title>
    <link>http://seclists.org/honeypots/2010/q1/10</link>
    <description>&lt;p&gt;Posted by Jason Lewis on Mar 03&lt;/p&gt;Slightly related, I was wondering what might happen if I made every&lt;br&gt;
query to the honeypot resolve back to the honeypot?&lt;br&gt;</description>
    <pubDate>Wed, 03 Mar 2010 14:44:13 GMT</pubDate>
    <guid isPermaLink="true">http://seclists.org/honeypots/2010/q1/10</guid>
  </item>
  <item>
    <title>Re: DNS honeypots?</title>
    <link>http://seclists.org/honeypots/2010/q1/9</link>
    <description>&lt;p&gt;Posted by Brent Huston on Mar 03&lt;/p&gt;One of the tactics our clients use is that they stand up one of our HoneyPoint Agents on a decoy box and then send all &lt;br&gt;
malicious and failed queries to that IP address. The HoneyPoint Agent then absorbs the traffic for analysis.&lt;br&gt;
&lt;br&gt;
You can find a little bit about it from one of our customers here, they wrote it up with us: &lt;a  rel=&quot;nofollow&quot; href=&quot;http://hurl.ws/cbhp&quot;&gt;http://hurl.ws/cbhp&lt;/a&gt;&lt;br&gt;
&lt;br&gt;
Let me know if that helps!&lt;br&gt;</description>
    <pubDate>Wed, 03 Mar 2010 14:21:42 GMT</pubDate>
    <guid isPermaLink="true">http://seclists.org/honeypots/2010/q1/9</guid>
  </item>
  <item>
    <title>Re: DNS honeypots?</title>
    <link>http://seclists.org/honeypots/2010/q1/8</link>
    <description>&lt;p&gt;Posted by chr1x on Mar 02&lt;/p&gt;This post looks pretty interesting!&lt;br&gt;
&lt;br&gt;
Let's analyze your requirement:&lt;br&gt;
&lt;br&gt;
1. Logging malicious queries&lt;br&gt;
2. Reject/Deny any possible dns attack attempt&lt;br&gt;
&lt;br&gt;
Well, from my point of view, going from the Honeypot concept which is&lt;br&gt;
track hackers, probably the best way that you can follow is to setup an&lt;br&gt;
IPS instead a Sensor. Personally, I don't see the purpose to have&lt;br&gt;
&amp;quot;Reactive&amp;quot; honeypot if the objective of a honeypot is to be the most&lt;br&gt;
open possible...&lt;br&gt;</description>
    <pubDate>Wed, 03 Mar 2010 02:56:08 GMT</pubDate>
    <guid isPermaLink="true">http://seclists.org/honeypots/2010/q1/8</guid>
  </item>


  <item>
    <title>Re: DNS honeypots?</title>
    <link>http://seclists.org/honeypots/2010/q1/7</link>
    <description>&lt;p&gt;Posted by Jason Lewis on Mar 02&lt;/p&gt;I just figured I'd setup something to log access and see what shows&lt;br&gt;
up.  I wasn't planning on directing traffic to the system.&lt;br&gt;</description>
    <pubDate>Tue, 02 Mar 2010 23:33:48 GMT</pubDate>
    <guid isPermaLink="true">http://seclists.org/honeypots/2010/q1/7</guid>
  </item>
  <item>
    <title>Re: DNS honeypots?</title>
    <link>http://seclists.org/honeypots/2010/q1/6</link>
    <description>&lt;p&gt;Posted by Jason Lewis on Mar 02&lt;/p&gt;Cool, this is the kind of thing I was thinking of doing.  I was hoping&lt;br&gt;
I wouldn't have to reinvent the wheel.&lt;br&gt;
&lt;br&gt;
Thanks.&lt;br&gt;</description>
    <pubDate>Tue, 02 Mar 2010 23:22:28 GMT</pubDate>
    <guid isPermaLink="true">http://seclists.org/honeypots/2010/q1/6</guid>
  </item>
  <item>
    <title>Re: DNS honeypots?</title>
    <link>http://seclists.org/honeypots/2010/q1/5</link>
    <description>&lt;p&gt;Posted by Jason Ross on Mar 02&lt;/p&gt;There's quite a lot of (bad and good) bots &amp;quot;out there&amp;quot; looking for DNS&lt;br&gt;
servers, particularly ones that appear to permit recursive queries to&lt;br&gt;
the Internet. Just leaving a box on the net that meets those criteria&lt;br&gt;
will collect a fair amount of queries.&lt;br&gt;</description>
    <pubDate>Tue, 02 Mar 2010 22:59:13 GMT</pubDate>
    <guid isPermaLink="true">http://seclists.org/honeypots/2010/q1/5</guid>
  </item>
  <item>
    <title>Re: DNS honeypots?</title>
    <link>http://seclists.org/honeypots/2010/q1/4</link>
    <description>&lt;p&gt;Posted by Valdis . Kletnieks on Mar 02&lt;/p&gt;On Tue, 02 Mar 2010 15:00:43 EST, Jason Lewis said:&lt;br&gt;
&lt;br&gt;
Out of curiosity, how do you get traffic directed to the honeypot without&lt;br&gt;
listing it in an NS entry for an SOA?  Give it a hostname like ns1.exampe.com&lt;br&gt;
and hope that works?&lt;br&gt;</description>
    <pubDate>Tue, 02 Mar 2010 21:53:10 GMT</pubDate>
    <guid isPermaLink="true">http://seclists.org/honeypots/2010/q1/4</guid>
  </item>
  <item>
    <title>Re: DNS honeypots?</title>
    <link>http://seclists.org/honeypots/2010/q1/3</link>
    <description>&lt;p&gt;Posted by Jason Ross on Mar 02&lt;/p&gt;Below is how I've got BIND set up in Debian Linux for a similar purpose.&lt;br&gt;
It sends all the queries to a log file, and returns an A record (and MX)&lt;br&gt;
of whatever value you'd like (I used RFC1918 space for this example).&lt;br&gt;
&lt;br&gt;
Not sure it's perfect, but it works pretty well for my purposes.&lt;br&gt;
&lt;br&gt;
Cheers,&lt;br&gt;</description>
    <pubDate>Tue, 02 Mar 2010 20:52:21 GMT</pubDate>
    <guid isPermaLink="true">http://seclists.org/honeypots/2010/q1/3</guid>
  </item>
  <item>
    <title>Re: DNS honeypots?</title>
    <link>http://seclists.org/honeypots/2010/q1/2</link>
    <description>&lt;p&gt;Posted by Tillmann Werner on Mar 02&lt;/p&gt;Jason,&lt;br&gt;
&lt;br&gt;
No need to run a server, you can simply sniff DNS traffic destined to&lt;br&gt;
that box. If you don't want to send back an ICMP port unreachable&lt;br&gt;
message, just block them using a packet filter.&lt;br&gt;
&lt;br&gt;
I have some DNS sniffer code for exactly that purpose I can send to you&lt;br&gt;
off-list if you are interested. tcpdump does the job, too, but mine&lt;br&gt;
integrates DNS processing and logging (for IN/A record queries via UDP).&lt;br&gt;
&lt;br&gt;
Tillmann&lt;br&gt;</description>
    <pubDate>Tue, 02 Mar 2010 20:24:08 GMT</pubDate>
    <guid isPermaLink="true">http://seclists.org/honeypots/2010/q1/2</guid>
  </item>
  <item>
    <title>DNS honeypots?</title>
    <link>http://seclists.org/honeypots/2010/q1/1</link>
    <description>&lt;p&gt;Posted by Jason Lewis on Mar 02&lt;/p&gt;Anyone have any pointers to dns honeypots or maybe just BIND&lt;br&gt;
configurations that would allow logging of malicious queries without&lt;br&gt;
actually executing them?&lt;br&gt;</description>
    <pubDate>Tue, 02 Mar 2010 20:08:05 GMT</pubDate>
    <guid isPermaLink="true">http://seclists.org/honeypots/2010/q1/1</guid>
  </item>


  <item>
    <title>Honeynet Project Forensic Challenge 2010/2 - browsers under attack</title>
    <link>http://seclists.org/honeypots/2010/q1/0</link>
    <description>&lt;p&gt;Posted by christian . seifert on Feb 27&lt;/p&gt;The Honeynet Project has revived an successful program from the past: The Honeynet Project Forensic Challenge 2010. The &lt;br&gt;
purpose of the Forensic Challenges is to take learning one step farther. Instead of having the Honeynet Project analyze &lt;br&gt;
attacks and share their findings, Forensic Challenges give the security community the opportunity to do so. In the end, &lt;br&gt;
individuals and organizations not only learn about threats, but also learn how to...&lt;br&gt;</description>
    <pubDate>Sat, 27 Feb 2010 20:01:26 GMT</pubDate>
    <guid isPermaLink="true">http://seclists.org/honeypots/2010/q1/0</guid>
  </item>

 

<!-- MHonArc v2.6.16 -->
<!-- MHonArc v2.6.16 -->

 

 

<!-- MHonArc v2.6.16 -->
  </channel>
</rss>
