>
> I usually look at DHCP as having two primary purposes, often only one is
> needed.
>
> 1. To conserve address space by using a group of addresses to handle a
> larger group of machines.
> 2. To dynamically configure (and allow easy reconfiguration) of clients
> IP information.
These are both excellent points, and also the only 2 reasons for using DHCP
>
Reading this thread, I would like to offer these observations, comments are
welcome, flames are not.
We use bootp and have for several years, and Item 2 is the reason we use it.
We are going to DHCP when it works with other_than_microsoft_clients, to
enforce configuration management of workstations.
Understand that DHCP is more robust than vanilla bootp but when I have
configured Xterminals, or printers, or clients, I need the MAC address and I
create entries in the "bootptab" based on MAC addrs, templates, and names
which are also static in the DNS. I use W. Venema's wrappers and to add
host(s) to the allow file I must use the following entry
bootpd,tftpd: 0.0.0.0
This just allows a client to connect to the bootpd server (on the local net),
then it get's its' IP address assigned and tftp goes on to download the
client's template of software based on the entry in the bootptab.
(NOTE: I ONLY do this for clients inside on my local net).
I would like to point out, that up until this point at which the "bootreply"
is returned the "client" has no IP address. To add a rule to the firewall
that allows ANY "bootrequest" to be broadcast to the internal network is in
my opinion a security hole. Granted the MAC addr must exist in the DHCP
configuration database, with a lease, but this does not stop a
"denial_of_service" attack by bombarding the boot server (DHCP/NT, or Unix
bootpd) in this case.
We are dealing with an IP filter and up to the point of the bootreply
we have only a MAC address. So to allow DHCP/bootp to broadcast into the
internal network would be unwise, additionally, you would need an ACL that
looks like the (0.0.0.0) and I do not believe this is a good idea.
I can understand putting a DHCP server (and by using DHCP we are tied
specifically to NT/Microsoft here) outside the internal network.
but I don't think this would be wise, (comments welcome here).
(I see using DHCP to boot clients, but not outside of the local net)
Since the original question was "using DHCP through a firewall" I would guess
the DHCP server must reside outside the firewall and is "booting" clients
on the internal network. I could not suggest doing this unless you need
to boot clients that are not on the local network and in this case you are
only using 1 DHCP server which enforces ALL leases, again, is this wise?
More thought needs to go into this. Possibly a NT firewall, since there is no
IP address assigned there could be no filter associated until the client gets
the bootreply.
Additionally, the DNS Must be able to use the WINS database, or your DNS
is not going to reflect valid WINS entries assigned by the lease.
And in this case, there goes any rules/policy using the DNS entries.
So this would make the DNS useless without the WINS2DNS conversion.
I guess this last statement implies the use of NT as a DNS platform with
mapping the WINS database to the DNS, This would likely be on the DHCP server
outside the firewall. Now this marries the DNS server and the DHCP server on
one platform outside the firewall, is this a good idea?
regards
stevep
References:
|
|
