HP 635n HP Jetdirect Print Servers - Practical IPv6 Deployment for Printing an - Page 30

not a good security practice. So, to update DNS, we'll need to use DHCPv6 and get a domain name. We would have to manually configure a cryptographic key to allow for secure D-DNS updates. How does this device get the DNS key? Well, this is a problem because it must be done securely and DHCPv6 isn't implemented with DNS key cryptographic distribution capability, which means it must be done manually, which means we have to find the devices to do it, which means we are back to square one. Even assuming we did get a D-DNS cryptographic key and we did implement a DNS-SD mechanism, one has to wonder that if DNS begins to resemble Active Directory in terms of logical configuration and mapping of services, and Active Directory is in use in most environments, why we aren't using Active Directory? Discovery: Active Directory With Active Directory Integrated DNS (ADI-DNS), we know that computers that are integrated into the AD can update their DNS records securely. However, there is no need to do service discovery via DNS. Computer objects within the directory have attributes that can be modified to enable nodes to discover objects using a search of the directory. That is all wonderful so far, but how many devices are integrated into the AD? How many mobile nodes and other various devices for which IPv6 development was a driver for have built in AD support? Doesn't AD support require administrative intervention to first create the object in AD to begin with? How does that administration happen with headless and mobile IPv6 devices? Attacks If you place yourself in an attacker's shoes and you need to find IPv6 devices because you have an IPv6 exploit, what would you do? Well, you could try the following: • Use IPv4 to find devices. Networks that are IPv4/IPv6 and haven't shut down IPv4 completely can utilize IPv4 to cut down on time to find Dual-Stack devices (via unicast or multicast). • Use Site-Local Multicasts to find IPv6 devices. Some devices incorrectly report ICMPv6 errors to multicast packets. By sending a Site-Local Multicast to a non-well-known UDP port you may be able to find those devices quickly. You can also use Link Local multicast packets to scan through UDP ports to find UDP ports that are open and responsive over a given protocol and then attempt to use Site-Local multicasts for the same protocol. As an example, attempt Service Location Protocol (SLP), LLMNR, and multicast DNS (mDNS) over site local multicast addresses to see if there are any implementations out there responding to them. • Search the DNS server for service records or attempt to get a Zone transfer to find all the devices. If you are able to find some valid domain names, guessing at hostnames is much easier than searching the IPv6 Identifier address space. • If you can find an LDAP server, see if you can search the directory for devices anonymously. What if you don't want to find devices but just want cause a lot of IPv6 disruption (or network mayhem)? • Blasting out site-local multicast addresses to randomized UDP ports with randomized hop limits is a good start. What if you want to compromise devices that you have found without relying on software exploits? • Use SNMP over IPv6 to try and find network agents that you can write MIBs on. Sometimes Access Control Lists have been specified to prevent this for IPv4, but were the ACLs updated for IPv6 when IPv6 was deployed? This is true of any management protocol, not just SNMP. • Check if the DNS servers support unsecured DNS updates. If so, modify entries or populate new service records. • Check for IPv6 web servers - they may not have the same security as the IPv4 web servers. 30