Re: results of the first honeyd challenge (dynamic honeynet?)

["Wim Mees" <Wim.Mees () vision rma ac be>]

> From rfc-2131 "Dynamic Host Configuration Protocol"
<quote>
2.2 Dynamic allocation of network addresses
...
In some environments it will be necessary to reassign network
   addresses due to exhaustion of available addresses.  In such
   environments, the allocation mechanism will reuse addresses whose
   lease has expired.  The server should use whatever information is
   available in the configuration information repository to choose an
   address to reuse.  For example, the server may choose the least
   recently assigned address.  As a consistency check, the allocating
   server SHOULD probe the reused address before allocating the address,
   e.g., with an ICMP echo request, and the client SHOULD probe the
   newly received address, e.g., with ARP.
</quote>

If you block on the honeypot all packets with source IP that of the dhcp
server, you will effectively block the ICMP echo requests, but the ARP
request/reply that went on beforehand will get through. It will depend on
the implementation of the DHCP server whether it considers this address
available or not.

If the DHCP server then hands out this address to a client, this client will
in turn probe with an ARP request to see whether this IP address is really
really free. Since you don't block the client, its ARP request will be
received by the honeypot and will receive and ARP reply from arpd. As a
result, the client will not accept the lease :(

The fundamental problem lies in the fact that you have on the one hand the
dhcp server that is owner of a given scope, and on the other hand you're
trying to "steal" addresses without disturbing the address manager. Because
the RFC did not foresee such a situation, you will always rely on
implementation aspects of specific products for your setup to work. It's a
bit like NAT breaking TCP/IP :)

A better solution would be to write a patch for arpd so that you can give
arpd a dhcp scope as a parameter and that it
1. at startup leases 75% of the number of addresses in this scope from the
dhcp server
2. monitors the number of leases provided by the dhcp server from this scope
to "real" clients and starts (re)leasing addresses when the percentage drops
below 70% or rises above 80%.

In this way you cooperate with the address space manager and avoid
conflicts.

Wim

----- Original Message -----
From: "Lance Spitzner" <lance () honeynet org>
To: "Wim Mees" <Wim.Mees () vision rma ac be>
Cc: <honeypots () securityfocus com>
Sent: Tuesday, April 01, 2003 6:09 AM
Subject: Re: results of the first honeyd challenge (dynamic honeynet?)


> On Mon, 31 Mar 2003, Wim Mees wrote:
>
> > Before a dhcp server will hand out a specific IP address, it will first
ping
> > the candidate address to verify whether the address is really free (and
the
> > receiving DHCP client will typically send an ARP request once more to
verify
> > whether the address it received is really really free). Since your arpd
is
> > at that time listening on this address, it will reply on ARP requests
and
> > ICMP echo requests and the dhcp server will never find an address that
is
> > free. It will effectively result in a DoS of your DHCP server.
>
> Interesting point.  One way around that (such as with a Honeyd deployment)
> is simply configure IPTables to block any ICMP requests from the DHCP
server.
> When the DHCP server attempts to ping a potential candidate IP address,
> it will get no response from the honeypot because the honeypot cannot
> respond.  As such, the IP will be assigned, and the new system will take
> over the MAC/IP address.  Not sure how well this would work, I've never
> tested it.
>
> Actually, a 'friendly' option for Arpd/Honeyd would be useful.  Such
> an option would mean the services do not reply or interact with specific
> systems based on their IP (such as DHCP servers).
>
> lance