Send dhcp-users mailing list submissions to
[email protected]
Advertising
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/dhcp-users
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of dhcp-users digest..."
Today's Topics:
1. Security of dhcpd on non-listening interfaces?
([email protected])
2. Re: Security of dhcpd on non-listening interfaces? (Simon Hobson)
3. Sporatic failure to renew (Friesen, Don MTIC:EX)
4. RE: Sporatic failure to renew (Patrick Trapp)
5. How to set reserved lease via omshell (Frank Price)
----------------------------------------------------------------------
Message: 1
Date: Tue, 1 Mar 2016 11:34:14 -0800
From: <[email protected]>
To: "'Users of ISC DHCP'" <[email protected]>
Subject: Security of dhcpd on non-listening interfaces?
Message-ID: <0a6601d173f1$56600160$03200420$@com>
Content-Type: text/plain; charset="us-ascii"
Ok, so now that my multiple chrooted dhcp servers idea was shot down in
flames I need to retreat to serving only the more secure vlans.
Some of you appear to know the code well. How secure is the server from
malicious packets on non-listening interfaces?
What I mean is, does the code identify and discard packets (both ip and raw
sockets) for ignored interfaces prior to doing risky things (like parsing
and memory reallocation)?
Are there links to discussions on this? I should check out the relevant
sections of code, but before starting from scratch I'll bet there's a wealth
of discussion somewhere.
------------------------------
Message: 2
Date: Tue, 1 Mar 2016 20:23:56 +0000
From: Simon Hobson <[email protected]>
To: Users of ISC DHCP <[email protected]>
Subject: Re: Security of dhcpd on non-listening interfaces?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
[email protected] wrote:
> Some of you appear to know the code well. How secure is the server from
> malicious packets on non-listening interfaces?
>
> What I mean is, does the code identify and discard packets (both ip and raw
> sockets) for ignored interfaces prior to doing risky things (like parsing
> and memory reallocation)?
>
> Are there links to discussions on this? I should check out the relevant
> sections of code, but before starting from scratch I'll bet there's a wealth
> of discussion somewhere.
I don't recall any discussion of this in the past, and I've been on here for
quite a few years.
As an alternative tack, can you separate the services onto two (or more)
servers ? In my experience, people looking at security to the level you appear
to be doing tend to distrust security that relies only on software
configuration - and for some of my customers at work that also means not
relying on VLANs for traffic separation.
------------------------------
Message: 3
Date: Tue, 1 Mar 2016 21:51:32 +0000
From: "Friesen, Don MTIC:EX" <[email protected]>
To: "'Users of ISC DHCP'" <[email protected]>
Subject: Sporatic failure to renew
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Has anyone had the experience of having Windows 7 fail to renew the initial
20 minute lease that is offered by the peer configuration? Would Windows 7 be
sensitive to packet lag? How much time between does Windows 7 allow between
REQUEST and ACK?
Background:
We are configured to hand out leases that range from 4 hours to 2 weeks.
A set of sites have last had their desktops imaged to Windows 7 about 6 years
ago, no changes since then.
We have been using ISC DHCP for 10 years, but recently relocated our servers to
another city.
Shortly after that a small percentage of these Window 7 desktops would
sporadically not renew the 20 minute initial lease that the peer configuration
hands out.
Don Friesen
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20160301/6ddff8ad/attachment-0001.html>
------------------------------
Message: 4
Date: Tue, 1 Mar 2016 21:59:42 +0000
From: Patrick Trapp <[email protected]>
To: Users of ISC DHCP <[email protected]>
Subject: RE: Sporatic failure to renew
Message-ID:
<1d507d610594d14f86d40d77c17e9e6626508...@exchangedsb.ruralnex.com>
Content-Type: text/plain; charset="iso-8859-1"
Is it the same clients that are not renewing?
Have you determined whether they are sending renewal requests vs the server not
honoring the requests?
Crazy thought just because the servers have moved - is the time-to-live set
short? I worked a situations where the TTL on the server was just enough to
reach every place in the office in question, but when they finally added
Internet access, it didn't have enough TTL for anyone to access that system
from remote offices.
Just throwing out ideas. I'm not familiar with the "initial 20-minute lease"
you refer to, but I don't use this system for my workstations, just network
access devices.
________________________________
From: [email protected] [[email protected]] on
behalf of Friesen, Don MTIC:EX [[email protected]]
Sent: Tuesday, March 01, 2016 3:51 PM
To: 'Users of ISC DHCP'
Subject: Sporatic failure to renew
Has anyone had the experience of having Windows 7 fail to renew the initial
20 minute lease that is offered by the peer configuration? Would Windows 7 be
sensitive to packet lag? How much time between does Windows 7 allow between
REQUEST and ACK?
Background:
We are configured to hand out leases that range from 4 hours to 2 weeks.
A set of sites have last had their desktops imaged to Windows 7 about 6 years
ago, no changes since then.
We have been using ISC DHCP for 10 years, but recently relocated our servers to
another city.
Shortly after that a small percentage of these Window 7 desktops would
sporadically not renew the 20 minute initial lease that the peer configuration
hands out.
Don Friesen
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20160301/83d55812/attachment-0001.html>
------------------------------
Message: 5
Date: Wed, 2 Mar 2016 01:06:05 -0500
From: Frank Price <[email protected]>
To: Users of ISC DHCP <[email protected]>
Subject: How to set reserved lease via omshell
Message-ID:
<cakqznuc0fc_wt5x3bpcsprs7xeduz4xybibeggqjki5dphd...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
After the recent discussion of reserved leases, I decided to try this out
in our environment and do a test with omshell. To my chagrin, I've played
with this all night and am no further along than I was. I'm
running isc-dhcpd-4.2.5, by the way.
Here's what I'm doing:
- enter omshell; give a server and key and connect.
- new lease
- set ip-address = 10.199.67.214
- open
At this point I get the object attributes, which include state =
00:00:00:02 (meaning it's an active lease). I should be able to mark this
as reserved, right? But how do I actually do that?
The man page for dhcpd, under LEASES, says:
Leases have the following attributes:
state integer lookup, examine
1 = free
2 = active
3 = expired
4 = released
5 = abandoned
6 = reset
7 = backup
8 = reserved
9 = bootp
This makes me think that reserved is an attribute of state, thus:
- set state = 9 ; update
- set state = 00:00:00:09 ; update
But I just get "can't update object: invalid argument" when I try to
update.
A desperate bit of googling led me to
https://lists.isc.org/pipermail/dhcp-users/2008-June/006519.html, so I
tried
- set flags = 04:00:00:00
but that just crashed dhcpd for me.
I'm clearly missing something and I'm sure it's obvious, but right now I'm
at sea. Anyone actually done this?
-Frank
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20160302/14540ae3/attachment.html>
------------------------------
_______________________________________________
dhcp-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/dhcp-users
End of dhcp-users Digest, Vol 89, Issue 3
*****************************************
