samba - Jun 2022 - Possible security issue with DHCP script.

On Mon, Jun 20, 2022 at 12:51 AM Zombie Ryushu via samba
<samba at lists.samba.org> wrote:
>
> I use a Strongswan VPN to connect via IPSec over VPN. Due to an error on
> my part, I set the user identity to olympia.pukey (192.168.0.4) - which
> is the hostname to one of my Domain Controllers. I use the script for
> Kerberized updates with Bind DLZ, and it accepted the zone update,
> changing the A Record to 192.168.0.234, the DHCP lease given by dhcpd.
> This broke domain Authentication. There is no check in the script to see
> if a DC occupied that hostname. I was able to manually fix it back. This
> could be used by a malicious actor to intercept domain logins.
I was thinking of a way to modify the script in order to minimize this
issue, but clearly every domain is going to be different. In our case,
we would also likely want to prevent our file servers from being
overwritten by a rogue client as well.
I'm wondering if there would be a good way of handling a blacklist
file, something that anyone using this script could implement that all
they would need to do is add a list of hostnames that the DHCP script
would ignore.

As of now, I blacklist certain hostname schemes (shown below) to
prevent a lot of the mass devices we don't need DNS resolution on in
our network. Adding more than one or two hostnames to this would get
tedious hence the suggestion above:


Regards,
Ralph

On Mon, Jun 20, 2022 at 9:06 AM ralph strebbing via samba
<samba at lists.samba.org> wrote:
>
> On Mon, Jun 20, 2022 at 12:51 AM Zombie Ryushu via samba
> <samba at lists.samba.org> wrote:
> >
> > I use a Strongswan VPN to connect via IPSec over VPN. Due to an error
on
> > my part, I set the user identity to olympia.pukey (192.168.0.4) -
which
> > is the hostname to one of my Domain Controllers. I use the script for
> > Kerberized updates with Bind DLZ, and it accepted the zone update,
> > changing the A Record to 192.168.0.234, the DHCP lease given by dhcpd.
> > This broke domain Authentication. There is no check in the script to
see
> > if a DC occupied that hostname. I was able to manually fix it back.
This
> > could be used by a malicious actor to intercept domain logins.
>
> I was thinking of a way to modify the script in order to minimize this
> issue, but clearly every domain is going to be different. In our case,
> we would also likely want to prevent our file servers from being
> overwritten by a rogue client as well.
> I'm wondering if there would be a good way of handling a blacklist
> file, something that anyone using this script could implement that all
> they would need to do is add a list of hostnames that the DHCP script
> would ignore.
>
> As of now, I blacklist certain hostname schemes (shown below) to
> prevent a lot of the mass devices we don't need DNS resolution on in
> our network. Adding more than one or two hostnames to this would get
> tedious hence the suggestion above:
I've also thought about putting DHCP clients dynamic DNS records in a
separate subdomain altogether. I.e.

contoso.com -- Main domain
corp.contoso.com -- AD domain
dyn.contoso.com -- Dynamic DNS registrations

Note that this *only* applies to DHCP clients. The majority of your
domain-joined machines (Windows and SSSD at least) should already be
performing dynamic DNS updates using their machine credentials, and
the ACLs on the records prevent one client from stomping on another
client's (DC's) records.