tag:blogger.com,1999:blog-79120005842636640002024-03-19T00:26:13.705-04:00IPAMIP Address Management (IPAM) topics related to IPv4, IPv6, DHCP, DNS, DNS security including DNSSEC, cloud IPAM, and related technologies with a perspective on effectively managing these critical networking functions.Tim Rooneyhttp://www.blogger.com/profile/01546393894956325009noreply@blogger.comBlogger118125tag:blogger.com,1999:blog-7912000584263664000.post-53221765686984135282021-11-12T14:19:00.001-05:002021-11-12T14:39:12.834-05:00Inglorious DDI<div class="entry-content">
<p>We all know how critical DHCP/DNS/IPAM (DDI) services are. Your
network cannot function without them. But like most foundational
elements of anything, they are certainly not glamorous...like good luck finding a home
designer who specializes in home foundations. I would not be shocked should HGTV pass on my brilliant concept for a foundation building show. I suppose most people would find a show detailing footing depths and concrete pouring techniques rather boring. </p><p>Nevertheless, there are countless shows for redesigning and remodeling homes. On most episodes the foundation is out of sight, out of mind. If it's stable, no one wants to pay it attention, they just expect it to keep doing its job, supporting the structure. Once in a while a foundational issue is brought up that unexpectedly threatens to raise the budget to heighten the drama. All work stops until the issue is addressed. And you'll notice that the owner never denies paying the extra amount to fix the issue. After all, any foundation issue must be resolved so the threat of compromise to the rest of the house is reduced. As the episode continues, there's no further mention of the foundation and attention shifts back to the upper floors and the magnificent reveal. </p><p>Whether on television or real life, it's inadvisable to ignore foundational issues. If your foundation fails, your beautiful remodel can come crashing down. Like the foundation of your house, DDI is the foundation of your network. To even access your network, a device requires a unique IP address; to access network resources, your users and devices require DNS. But for many, the prospect of managing DDI can evoke similar reactions as those from HGTV regarding my new show proposal. It’s inglorious and often tedious – but – it better be
built right! </p><p>If your DDI foundation fails to properly map space for your IoT deployments, to automate address assignments across multi-clouds, to add a layer of detection against malware, or to effectively support your many other network initiatives, your progress will be halted in its tracks. All efforts to progress your transformational business initiatives will prove fruitless. So whatever network services you're developing and managing for your business, make sure you foundation is stable, reliable and scalable to meet your current and future needs. Establishing a strong DDI foundation now will eliminate the need for future expensive foundation repairs.</p>
<p>Fortunately if you’re using the right DDI tool like IPControl from
Diamond IP, you can largely place DDI on auto-pilot. With its rich
automation and adaptation capabilities, you can integrate DDI into
broader IT workflows. DDI can largely become self-managing. For example, you can monitor network address capacity and automatically allocate more space if needed. While automating common IT tasks involving IP address or DNS
assignment can vastly reduce your DDI workload, fully automating every
task may be unrealistic. And you may not have the resources to automate
as much as you’d like. After all, once automation flows are operational,
they still require attention occasionally due to vendor API changes and new features.</p>
<p>Diamond IP can help with integrating DDI into your flows with our
REST API and Cloud Automation Appliance (CAA). If you’d prefer to use a
DDI service, Diamond IP can help there too! Diamond IP offers a
two-tiered DDI service:</p>
<ul><li>Our Sapphire Infrastructure Management (SIM) service provides
real time monitoring, troubleshooting, patching and upgrading of
deployed Sapphire DDI infrastructure.</li></ul>
<ul><li>Our managed IPAM service builds on the SIM service to add the
performance of DDI moves, adds and changes within your IPControl systems
and deploying DHCP and DNS updates.</li></ul>
<p>Our DDI-as-a-service enables you to focus on the more glamorous
aspects of your IT projects. Seek the glory in deploying new
applications for growing your business. And with our DDI automation and/or services, you
can strive with full confidence that your requisite DDI foundation is
rock solid.</p><p><br /></p></div>Tim Rooneyhttp://www.blogger.com/profile/01546393894956325009noreply@blogger.com0tag:blogger.com,1999:blog-7912000584263664000.post-41333877503789506552021-10-27T13:36:00.000-04:002021-10-27T13:36:14.441-04:00IPAM-As-Code<p>IP Address Management (IPAM) is often considered a necessary evil by most IT and Operations Engineers. Every time a new virtual instance in the cloud or on prem is instantiated, or an old fashioned server is deployed, both an IP address and DNS name need to be assigned...every time. Of course, the assigned IP address must be unique at least within a given routing domain, and the DNS name must be uniquely resolvable to enable users and other machines to connect with it. Beyond their respective uniqueness requirements, these core configuration elements must also be relevant to their respective deployment realms, such as subnet and DNS domain, so just any old assignment won't do. In addition, with the speed of today's business demanding a highly dynamic rate of change in creating, realigning or destroying virtual instances across a multi-cloud network, the assignment process must be always available and instantly responsive to not impede your business velocity.</p><p><span style="vertical-align: inherit;"><span style="vertical-align: inherit;">While assigning IP addresses and DNS names using manual methods such as spreadsheets is doable albeit cumbersome if not error-prone when addressing the first two requirements for uniqueness and context, they collapse under the third requirement for highly available and highly responsive assignment performance. An automated IP and DNS assignment process is needed with the ability to modularly plug into your IT and Operations flows </span></span>to successfully meet this third requirement, not to mention the first two.<span style="vertical-align: inherit;"><span style="vertical-align: inherit;"> </span></span>Clearly a performant, scalable API-driven solution with a reliable repository is required to fortify your infrastructure-as-code approach, supplying IPAM-as-code capabilities. </p><p><span style="vertical-align: inherit;"><span style="vertical-align: inherit;">When using terraform, Ansible, Service Now or any infrastructure or provisioning system, the incorporation of the IP and DNS assignments eliminates the manual process of consulting a spreadsheet or even non-integrated IPAM repository. These systems can request an IP and DNS assignment during flow execution by invoking your IPAM system's API, virtually obscuring your IPAM system to the joy of most IT and Operations Engineers! Finally, no more IPAM! </span></span></p><p><span style="vertical-align: inherit;"><span style="vertical-align: inherit;"><span style="vertical-align: inherit;"><span style="vertical-align: inherit;">Well, not so fast. While the mundane process of manual assignment vanishes, you'll still require visibility and some controls. You'll need to be able to track assignments and to assure adequate addressing capacity for each of your addressing domains. For example, you may need to manage assignments and capacity across multiple public cloud services, internal data centers, branch offices, SDWAN-connected sites, and remote and home workers. With a comprehensive IPAM solution you can maintain a cross-domain perspective spanning these diverse network environments through a single pane of glass, all while evanescing during the provisioning process.</span></span></span></span></p><p><span style="vertical-align: inherit;"><span style="vertical-align: inherit;">IPControl from Diamond IP is a performant, scalable, REST API-driven solution with a reliable repository and a pervasive perspective to enable you to plug into any programmable API environment for automation, while providing comprehensive IP and DNS visibility. Diamond IP solutions offer the broadest, most flexible IPAM solutions, from enabling IPAM-as-code as highlighted here, to IPAM-as-service with our managed services and everywhere in between as well as extensive DNS security solutions. Please contact me to learn more about how to make your IPAM disappear!</span></span></p>Tim Rooneyhttp://www.blogger.com/profile/01546393894956325009noreply@blogger.com0tag:blogger.com,1999:blog-7912000584263664000.post-39388806383560820342021-08-11T09:14:00.000-04:002021-08-11T09:14:31.884-04:00DNS is to Devices as Google is to People<p>Thanks to search engines like google, locating articles, blogs, opinions, and even bona fide information on the Internet is as simple as posing a question in a web browser. Just type in your query then click on one of the search engine results to access the corresponding content. Of course, between the point when you click on a result and arrive at the linked page, the critical function of the domain name system (DNS) performs its crucial yet hidden role. Each search result displays text to the searcher representing content they can expect to find if they click on it. With the hypertext markup language (HTML), behind the text lies the corresponding uniform resource locator or URL. The URL is in the form of a web address that you might enter into your web browser, like www.google.com. </p><p>Names are helpful for humans using the Internet to identify desired destinations, but your laptop, mobile, watch, etc., generically "device," connects to your destination using the Internet Protocol (IP). The IP header enables specification of the destination IP address to route the request, typically using hypertext transfer protocol (HTTP), to the desired destination. So how does your device translate the linked URL into an IP address? DNS enables administrators to publish their domain names and corresponding IP addresses to direct devices seeking access to applications running on servers configured with those IP addresses.</p><p>Note that the URL corresponding to a given click may have slashes, question marks and other characters that are passed within the HTTP (or corresponding protocol) request to the destination. DNS translates only the domain name portion of the URL to an IP address. So a URL of "www.example.com/information?query=yes" would trigger a DNS lookup of www.example.com. Once the IP address of the server hosting the corresponding resource has been identified thanks to DNS, the application protocol can use these additional parameters to parse the request accordingly. And while HTTP is the example protocol I'm using to illustrate this process, DNS can translate destinations to IP addresses for any Internet protocol, include email, file transfer, even voice and video communications. And DNS can do more than translate destinations into IP addresses, enabling the location of desired network services, alias device names, security credential affirmations, and more.</p><p>DNS facilitates navigation of the Internet by humans for a wide variety of applications and services. It also eases the job of administrators managing IP networks. For example, to migrate to a new web server on a new IP address, administrators need only update DNS to change the IP address associated with the web server's address records. The end user need not know that the web content is actually being served by a server in a different location, in the cloud, or on a content delivery network. Administrators can thus publish stable names for resources and manage IP address mappings behind the scenes with DNS. This naming stability not only facilitates consistent user reachability and access but also reachability from other sites which link to your content.</p><p>DNS name stability is also indispensable for machine-to-machine communications, particularly within software defined networks and private or public cloud virtualized network functions (VNFs). A series of VNFs may be required for data stream traversal to provide a given end-to-end service. For example, a new service promising secure, optimized communications could accept user data, voice or video traffic and route this input stream through a firewall VNF, then to an application traffic optimizer VNF and on to an encryption VNF. This <i>service chaining</i> concept enables flexible and modular services implementation. </p><p>If the service proves popular, the input traffic could exceed the processing capacity of one or more VNFs in the chain. Implementing the service such that a predecessor VNF references its successor VNF in the chain by name instead of IP address, multiple VNFs sharing a common domain name could be provisioned as needed to expand capacity elastically. The encryption service component for example could comprise three encryption VNFs sharing a common domain name, e.g., encrpytservice.example.com. The optimizer VNFs would locate the next link in the service chain via DNS (querying encrpytservice.example.com) and route the stream to one of the three corresponding VNF IP addresses returned by DNS. When spinning up new VNFs to support a given service in the chain, simply add the new VNF's IP address to the service's domain name resource record set in DNS. This streamlines the provisioning of elastic capacity for each chained function provided by instantiating the VNF and updating DNS without having to reconfigure predecessor VNFs. </p><p>DNS has proven an indispensable component for the smooth operation of today's IP networks, enabling devices to "google" destinations to which to connect, whether initiated by humans browsing or using other Internet applications, by network administrators to more easily manage their networks behind the scenes and for software defined networks in facilitating scalability and elasticity. If you'd like to learn more, please contact me!</p>Tim Rooneyhttp://www.blogger.com/profile/01546393894956325009noreply@blogger.com0tag:blogger.com,1999:blog-7912000584263664000.post-31993138880096522682021-07-15T13:40:00.004-04:002021-07-15T13:42:00.488-04:00Call me...on DNS<p>DNS has proven incredibly versatile and scalable in resolving email, web, and application services names to IP addresses across the global Internet for over three decades. And its versatility seems to have no limits as DNS can even be used to map telephone numbers into IP addresses too. The means to perform this mapping function is useful for voice applications, not to mention other generic applications requiring resolution with one or more layers of indirection. The ENUM (E.164 telephone number mapping) service has been defined to support telephone number resolution. ENUM supports the mapping of telephone numbers, in ITU E.164 format, into uniform resource identifiers (URIs). A URI is an Internet identifier consisting of a uniform resource name (URN) and a uniform resource locator (URL). A simple example: for URL http://www.ipamworldwide.com with URN file.txt, the corresponding URI would be http://www.ipamworldwide.com/file.txt. </p><p>The mapping of E.164 numbers (or other arbitrary domain names for that matter) to URIs is performed primarily using the Naming Authority Pointer (NAPTR) resource record type in DNS. NAPTR records were initially defined to provide a means to iteratively resolve an arbitrary string into a URI for the Dynamic Delegation Discovery System (DDDS). Some background on DDDS is provided in RFC 3402, but it initially stemmed from the desire to define a resolution process that could enter with a resource name (e.g., a particular application or piece of data) which in itself, contains no network location information, and resolve it to a destination resource identifier by applying a series of iterative rules from a database, DNS in this case. This separation of the specification of the resource name from the process to locate or resolve it facilitates the making of changes and re-delegations of resources without impacting the end user application’s naming convention.</p><p>The NAPTR record enables the specification of such rules within DNS, often using multiple record types including A, AAAA, SRV and even iterative NAPTR records to fully complete the resolution process. Each NAPTR record translates a given entry string, i.e., a valid DNS domain name, into another name or regular expression that can be applied to the input string to derive the next name to lookup. This process iterates until a terminal rule is reached and the final result is returned to the requesting application.</p><p>The record data portion of the NAPTR record type contains Order and Preference fields to enable prioritization of multiple records for the same name much like SRV records, a Flags field to denote the resource record type to lookup next, a Services field to indicate the translation type, e.g., URI to URL, ENUM service to URI, etc. as well as Regular Expression and Replacement fields. The Regular Expression field enables entry of a sed-style regular expression for evaluation to derive the next lookup name and Replacement denotes the next lookup name explicitly.</p><p>For example, when used to lookup an E.164 telephone number the query name comprises a destination telephone number (with digits reversed much like IPv4 addresses in an in-addr.arpa domain name and suffixed with <i>e164.arpa</i>). The Services field would be "E2U" to denote E.164 translation and the regular expression or replacement would resolve a destination, e.g., a Session Initiation Protocol (SIP) server, mailto URL, or other URI-formatted destination. The resolver would then perform a lookup of the resolved destination name for the type defined in the NAPTR Flags field (typically SRV, A or AAAA) to ultimately complete the resolution process. </p><p>The 3G partnership program, which is a standards body for advanced mobile systems, in conjunction with the European Telecommunications Standards Institute (ETSI) defined the use of NAPTR records for mobile services resource location using DNS in its ETSI TS 129 303 / 3GPP TS 29.303 document: Universal Mobile Telecommunications System (UMTS); LTE; Domain Name System Procedures; Stage 3. This standard stipulates use of "Straightforward NAPTR" or S-NAPTR as defined in RFC 3958, which limits the lookup types to SRV, A, or AAAA types and ignores regular expression processing. For 3GPP applications, e.g. 5G, lookups are performed for particular node names of given types not E.164 telephone numbers, though this merely elucidates the versatility of the NAPTR resource record type. </p><p>Management of a multitude of domains, zones, and node names, not to mention direct and indirect resolution methods via various record types could be overwhelming especially given the scalability requirements of most service provider networks. Use of a highly scalable, available, and flexible IP address management (IPAM) system such as IPControl from Diamond IP by BT can vastly simplify administration of these multiple dimensions of complexity with inherent automation to facilitate provisioning accuracy with scale. IPControl helps the largest service providers on Earth manage their IP space and DNS configurations. Please contact me to learn more. </p>Tim Rooneyhttp://www.blogger.com/profile/01546393894956325009noreply@blogger.com0tag:blogger.com,1999:blog-7912000584263664000.post-49690437689899612242021-06-22T12:16:00.004-04:002021-06-22T12:19:13.833-04:00Is DHCPSEC a thing?<p>Dynamic Host Configuration Protocol (DHCP) and the Domain Name System (DNS) are both foundational IP network services, enabling devices to connect to networks (via automated DHCP address and parameter assignment) and to navigate networks (via DNS name-to-IP resolution). DNSSEC refers to DNS security extensions, which is an Internet standard for signing and validating digital signatures on DNS response data. This process requires the signature-validating resolver to possess a trusted key which validates the response data signature, and by so doing, authenticates the data as published by the domain administrator and affirms the integrity of the data as matching that which was published. A single trusted key can be used to validate the entire Internet name space, thanks to the DNSSEC "chain of trust" mirroring the immanent DNS domain hierarchy up to the root zone. </p><p>In the DHCP realm, there is no such hierarchy and a given mobile device could roam across multiple networks, each with its own independent DHCP services. Thus it would be impractical for each DHCP client to possess a trusted key for every possible DHCP server it may encounter. For this reason, the DHCP authentication mechanism defined in RFC 3118, which works similarly, requiring <i>a priori</i> knowledge of a given server's token (as opposed to a single trusted key), has seen few if any widespread implementations. Thus without a means to authenticate, the client must trust that its offered IP address is legitimate. Should this be of concern?</p><p>As with any risk analysis process, the initial step in formulating a security strategy, each organization must assess the relative risk of occurrence of such events and consequential outage costs against mitigation costs. While DHCP is a critical network service for initializing devices for operation on an IP network, DHCP is typically deployed within an organization to initialize internal or visitor devices. Nevertheless, insider threats and malware serve as possible attack origination points. </p><p>If an attacker managed to establish a rogue DHCP server within your network, they could initialize DHCP clients perhaps with valid IP addresses but falsified supplemental information. For network boot clients, DHCP parameters could be supplied from the rogue DHCP server to load malware infested code. For general devices, forged parameters could be supplied with the DNS servers option to direct devices to issue DNS queries to an attacker's DNS server. Presumably if an attacker can stand up a rogue DHCP server they could also configure a rogue DNS server even if you're diligent about applying ACLs to DNS queries traversing your Internet access points. A rogue DNS server might be configured to direct unsuspecting clients to forged sites to load malware or collect sensitive information for example.</p><p>If you are regularly monitoring your network for IP address occupancy and matching discovered addresses with known legitimate IP address assignments, you could easily detect such rogue devices, each of which require routable IP addresses themselves. Of course a smart attacker would disable ping responses, so your discovery mechanism must be broader to allow the option to check router ARP tables for recently active IP addresses as well.</p><p>You can also configure your legitimate DHCP and DNS servers to detect rogue activities. Configuring your DHCP servers as authoritative for configured subnets and pools enables the server to NAK IP lease requests or confirmations for which it did not offer. Investigation of NAK events can help with detection of rogue DHCP servers. From a DNS perspective, in addition to the ACLs on which legitimate servers can make queries within and outside of your network, configuring a DNS firewall feed can block queries to known malware domains and identify malware-infected devices. </p><p>In addition to rogue DHCP servers, other risks to your DHCP services include server availability and integrity, address pool depletion, server operating system, API, and physical attacks, and denial of service. For each of these risks, you should assess the likelihood of the occurrence of each risk, impact of each occurrence, and alternative mitigation approaches and costs. Outage costs for DHCP could be severe, as any network device requiring a new or renewed DHCP lease could be left unserved and therefore unconnected. For this reason, most organizations mitigate server or network outage risks by deploying redundant DHCP servers. Other mitigation approaches to these various risk factors are outlined in our new Diamond IP white paper we'd be happy to share with you. Just contact me or our <a href="mailto:btdiamondip-sales@bt.com?Subject:DHCPSecurity" rel="nofollow" target="_blank">sales team</a> for your copy. So while DHCPSEC isn't a thing (though it was actually proposed in a defunct Internet draft from 1997), securing DHCP merits careful consideration, as does securing other servers and protocols operating within your network.</p>Tim Rooneyhttp://www.blogger.com/profile/01546393894956325009noreply@blogger.com0tag:blogger.com,1999:blog-7912000584263664000.post-1099945317388895092021-05-26T14:00:00.000-04:002021-05-26T14:00:09.487-04:00The Numerous Components of a Zero Trust Network<p>In the face of a rising tide of network infiltration attempts via increasingly diversified attack vectors, enterprises must constantly remain vigilant and proactive in managing system monitoring and attack detection solutions. Whether you realize it or not, IP address management (IPAM) plays a key role within your overall network security strategy. Core IPAM functions, including tracking IP inventory, allocating address space, monitoring network access through DHCP and discovery, and various DNS security tactics not only serve as requisite network functions but are critical to your network security strategy. As the sophistication of attacks continues to spiral, defensive strategies including IPAM must likewise evolve to keep pace if not outpace nefarious exploitation of network and system vulnerabilities.</p><p>The concept of <i>zero trust networks</i>, originally posited by Forrester Research a decade ago, is rising in prominence as a fundamental network security approach within enterprises, across Internet of Things (IoT) environments and even in evolving macro developments such as secure access service edge (SASE). As the name implies, zero trust networks begin with the assumption that no user or device is implicitly trusted. Contrast this with the castle-and-moat philosophy where users and devices within a network are implicitly trusted and defenses are focused on detecting and repelling attacks originating externally to the network. As remote workers having accessed your networks from a variety of computing devices with high mobility are now returning to offices, your network is increasingly vulnerable to attacks originating both within and outside your network. </p><p>Implementing zero trust requires the identification of your most critical or sensitive data and enveloping it within a <i>protect sector</i>. Having identified your most important data, map how that data flows within and through your network to users, administrators or other systems. This step facilitates a tight scoping on the permissibility of such data across your network into <i>micro-perimeters</i>, comprised of the data sources, destinations and network paths. </p><p>Admittance of users within a micro-perimeter requires employment of the principles of user authentication, device authorization, and minimal privilege access to allow users with approved devices to access only those portions of the data required for their respective responsibilities. After you’ve defined your micro-perimeters within your network via these admittance strategies as well as network access and flow controls, continual monitoring and analysis of data flows enables detection of anomalies as well as attempted or successful perimeter violations to initiate response and recovery actions. Automating the detection, characterization and deterministic actions based on certain events is recommended to reduce the window of attack exposure and to quickly remediate infringements and to shore up defenses. </p><p>As with every network initiative, IPAM plays a key role in zero trust networks deployment. Your fundamental IP address plan and allocation strategy facilitates implementation of address-based security policies. Once you’ve defined each of your critical data and general network flows, you’ll need to define its micro-perimeter, which from a network perspective, would largely entail constraining what network endpoints (IP subnets or individual IP addresses) can access repositories housing the data by IP address and perhaps even defining access lists on the path along the way between them. An IPAM system affords quick and easy access to such information by inventorying subnets as well as IP address-to-host associations.</p><p>In terms of user authentication and device authorization, DHCP-initiated, autoconfigured, and cloud system IP address assignments must be tracked to detect devices present on the network with respect to authorized devices. Thus, many zero trust authentication solutions incorporate 802.1X and certificate-based authentication which can be supplemented by various forms of discovery to identify potential unauthenticated devices and users. </p><p>DNS also plays a key role within zero trust networks. As the first step in establishing an IP connection, DNS can be configured to respond differently to the same query from different resolvers using DNS views, a feature which enables a DNS server to respond with differing answers based on certain criteria including query source IP address. Views define match criteria to resolve a particular version of a zone via address match lists. For example, two views for an internal zone can be established, one which includes resolution to a server housing sensitive data and another that does not resolve the corresponding domain name. Similarly, views can restrict resolution data accessible by IoT devices which reside on dedicated IoT networks or subnets. </p><p>When a device becomes authorized, its corresponding IP address can be added to the address match list corresponding to the view that resolves the destination hosting the sensitive data. The only hitch is that the DNS service typically needs to be restarted. You could alternatively soften the per host authorization access to such DNS resolutions and perhaps just match on addresses within a given subnet or set of addresses if authorized devices are known <i>a priori</i> to emanate from a given address pool or set of subnets and pools. The device assignment to a particular pool can be configured within DHCP as well, and the device could be assigned an address from such a pool upon successful authorization. This would enable static definition of your view statements though require integrated DHCP address assignment based on external inputs (device authorization).</p><p>Your IP address plan, device initialization strategies (DHCP, SLAAC, etc.), and DNS name resolution configuration all serve as foundational components within a zero trust network, particularly with respect to provisioning and operation. From the monitoring and defense perspectives, auditing and forensics of network activity including potentially DHCP and DNS transactions and IP address discovery history serve as critical inputs. And DNS security measures can supplement broader network defense-in-depth strategies by monitoring for malware DNS queries or data exfiltration via DNS tunneling. A comprehensive IPAM solution such as that from Diamond IP can serve as the underpinning for your zero trust network deployment to facilitate definition and management of network micro-perimeters, DHCP pool criteria, IP discoveries, DNS view definitions and DNS security features.</p><div><br /></div>Tim Rooneyhttp://www.blogger.com/profile/01546393894956325009noreply@blogger.com0tag:blogger.com,1999:blog-7912000584263664000.post-66304345311020544192021-05-13T12:56:00.000-04:002021-05-13T12:56:15.847-04:00Introduction to the Industrial Internet of Things<p>The Internet of Things or "IoT" refers to the evolution of the Internet beyond connectivity and interaction among traditional user-operated devices like PCs, tablets, phones and similar types of devices into the realm of connectivity and interaction with non-user operated devices such as sensors, monitors and remotely controllable devices. Internet-enabling such “unmanned” devices allows them to autonomously report events, updates, status changes, or to perform remote actions commanded by users or other devices via the Internet. The popularity of home assistants, security systems, video doorbells, thermostats, door locks, etc. evinces the continuing expansion of IoT devices within residences. </p><p>IoT also boasts exceptional growth prospects for all types of industries such as utilities, energy, manufacturing, pharmaceuticals, educational institutions, municipalities, and others. This enterprise realm of IoT is referred to as the <i>industrial IoT</i>, or IIoT, where sensors, monitors, and controllers can be deployed indoors or out, often in ruggedized form factors. IIoT applications range from those broadly applicable across vertical industries including remote surveillance and security monitoring systems to provide expanded “eyes and ears” on buildings, factory floors, remote assets, etc., to specialized forms such as programmable logic controllers (PLCs) or actuators that can enact operational controls such as adjusting flow controls for production lines or pipelines. Remotely accessible sensors or controls can increase the breadth and depth of an organization’s visibility and control to achieve organizational objectives including automation, cost savings, timeliness and improved customer satisfaction.</p><p>IIoT devices by definition require Internet Protocol accessibility. Note that some types of remote sensors or “things” do not use IP protocols natively but can interface with an IP network through a border translation router. Wired IIoT devices can generally use native IPv4 or IPv6 protocols but certain wireless IIoT devices require optimization, particularly those deployed in remote areas, to enable them to conserve power (sleep often) and minimize bandwidth requirements (send small messages). The IETF has published several RFCs defining an IPv6 adaptation layer to facilitate Internet Protocol communications among IoT and non-IoT devices, termed <i>IPv6 over Low -Power Wireless Personal Area Network (</i>6LoWPAN). The adaptation layer serves to optimize native IIoT device traffic on IEEE 802.15.4 (2.4GHz), Bluetooth and low power Wifi networks for example to interface with native IPv6 routers and application servers. </p><p>From a network topology perspective, IIoT devices could be considered general IP hosts sprinkled across existing subnets as is the case with most residential deployments. Alternatively, one could allocate an independent IP block(s) to facilitate IIoT application-specific capacity, security and manageability practices. Such "air gapping" separation of IIoT devices from the enterprise network adheres with judicious network security practice and is actually one of the core principles defined in the International Engineering Consortium IEC 62443 standard, entitled <i>Industrial communication networks - IT security for networks and systems</i>. </p><p>Maintaining separation of the enterprise network from the IIoT network and even among differing zones within the IIoT network enables the isolation of malware for example within a separated zone assuming it is detected and quarantined before it can spread. The recent Colonial Pipeline ransonware attack actually infiltrated the organization's enterprise IT network systems, which was separate from their pipeline or operational technology (OT) networks. While full details about the attack are yet unpublished, the company's shutdown of the pipeline sought to contain any spread that may have crossed the IT-OT zones beforehand.</p><p>Separation of network zones with well-defined and guarded conduits between them is an effective means to contain a malware outbreak. Another core principle of the IEC 62443 standard is also a widely-recommended security practice: defense in depth. A layered security approach which enables multiple opportunities to detect and defend against attacks form multiple perspectives increases the likelihood of success. While close inspection of network traffic traversing conduits or firewalls between security zones provides one layer of protection, others should be sought to improve detection and protection performance. For example, DNS is commonly used by IIoT devices to locate centralized reporting or data aggregation systems. Use of DNS enables network administrators to modify the IP address plan as needed without having to update every IIoT device's configuration if hard-coded IP addresses had been required. A host domain name may remain static, but DNS enables an easy change to its corresponding destination IP address.</p><p>Given the prevalence and convenience of employing DNS to resolve domain names within the OT network or between IT/OT networks, close examination of DNS query and response data offers an opportunity to add a defense layer to detect the presence of malware. Malware typically uses DNS to locate a malware author's server on the Internet, enabling the perpetrator to provide instructions or code updates to successful malware infestations. DNS offers the attacker the same benefit of easily changing his/her IP address over time to evade detection. Use of a DNS firewall in such an environment can add a layer to your defenses to improve the probability of attack detection and response. </p><p>From an IP address management perspective, a centralized IPAM system can help you confidently deploy IIoT devices by providing the ability to manage IT and OT address spaces separately yet holistically, on premises or in the cloud. Discovery of device IP addresses in the terrestrial or cloud IT and OT networks enables tracking of device inventory, also a key tenet of network security: identifying network occupants, particularly those that shouldn't be. Managing DNS is another core IPAM function that enables the management of host domain name to IP address resolution, as well as key DNS security functions like DNS firewalls, DNS tunneling detection and DNSSEC. If you'd like to learn more about how IPAM can simplify your network management processes for IIoT, please contact us.</p>Tim Rooneyhttp://www.blogger.com/profile/01546393894956325009noreply@blogger.com0tag:blogger.com,1999:blog-7912000584263664000.post-89911385007169703902021-04-16T16:40:00.000-04:002021-04-16T16:40:06.928-04:00Open Your Eyes to Better Network Security<p>Let's face it, your business relies on your network. From email to web browsing, and video meetings to chats, your network is indispensable to the usability of these applications that facilitate basic work functions like collaboration, communication, education and sales. Your network is mission-critical and the performance and availability of your network is paramount. Recognizing this, many organizations actively manage and monitor their networks in order to detect performance degradations and outages on network links, routers, switches and computing infrastructure. Such proactive monitoring affords an early warning system for teams responsible for network uptime and performance to identify and begin troubleshooting issues, not to mention potential security events, before network users are affected. Deployed redundancy of links and infrastructure can provide uninterrupted performance from the end user perspective, while allowing time for troubleshooting teams to rectify the situation.</p><p>Surprisingly, some of these same organizations fail to apply the same discipline to monitoring DHCP and DNS servers, which are equally mission-critical network services given their fundamental roles of network admittance via DHCP and navigability through DNS. If a user cannot access your network due to a DHCP issue, it won't matter how perfectly the network runs. Likewise if DNS resolution malfunctions, user frustration would also taint perceptions of your otherwise well-managed network. I'd certainly advise you to apply the same monitoring, management and resiliency functions to DHCP and DNS if you don't already.</p><p>But beyond these foundations of redundancy deployment and status monitoring, DHCP and DNS in particular provide a treasure trove of data regarding the devices and application activities across your network. Tracking of requested DHCP options upon bootup, one can ascertain the type of device attempting to connect to your network. This information along with the device's associated client identifier or MAC address helps to identify what devices of what types are attempting to access your network. You can configure your DHCP servers to filter access attempts and permit or deny access as appropriate. In addition, logging of this information can provide insights on your network and the devices using it. Tracking of devices accessing your network is certainly valuable in helping secure your network. Forensics analysis of DHCP transactions can help narrow down devices and possibly device owners potentially engaged in nefarious activity, e.g., what devices had active leases at the time of a particular event in question. </p><p>Going beyond device initialization and access information that DHCP logging can provide, monitoring DNS transactions enables you to track network activity after the device has initialized and while active on your network. Every network connection generally begins with a DNS query to map a desired destination or link into its IP address. Browsing to a website typically spawns several additional DNS queries to locate images, videos, linked pages, ads, affinity sites, etc. Visibility to this information provides valuable information from a security standpoint. Users opening email attachments or otherwise instigating malware downloads generally initiate connections preceded with a DNS query. Devices infected with malware typically also use DNS and can connect to the malware author's command and control center for instructions, software updates, or to send sensitive data through DNS tunneling. Malware employing domain generation algorithms (DGAs) to attempt to contact its command and control center based on an algorithmically-determined domain name, e.g., based on the date and time, would query derived domains in search of instructions. Monitoring and logging of all DNS transactions, queries and responses, can help you identify these conditions on your network.</p><p>Several log collector tools exist to enable aggregation of DHCP and DNS logs across your network, affording you visibility to logged transactions and events. However, while logging for DHCP transactions is sufficient, logging for DNS on most implementations logs only queries and not query responses. While useful, lack of visibility to query responses hinders your ability to detect and analyze malware query responses, DNS tunneling transactions, and DGA domain access attempts by providing only half of the requisite information. That's why we've developed the Sapphire A30 IPAM Auditor appliance which enables DNS and DHCP packet capture from deployed BT Sapphire DHCP and DNS appliances. </p><p>The IPAM Auditor provides rich graphical reports displaying query and response trends, filtering by various criteria such as queried record types or top talkers, and for transaction drill down to specific DNS query and response packets. Capture of log data such as the response policy zone (RPZ, aka DNS firewall) events provides reporting on potential malware queries, and tracking of not only queries but appliance hardware vital statistics provides visibility to individual and aggregated DHCP and DNS appliance metrics. The IPAM Auditor provides visibility to the status of your mission-critical DHCP and DNS infrastructure, while providing DHCP and DNS transaction summaries, events, and drill downs to the packet level for spot checking, investigative reporting or forensics analysis. Feel free to review our <a href="http://www.ipamworldwide.com/btdiamondip/ds_IPAMAuditor.pdf" rel="nofollow" target="_blank">data sheet</a> and please contact me for more information and a demo.</p><p><br /></p>Tim Rooneyhttp://www.blogger.com/profile/01546393894956325009noreply@blogger.com0tag:blogger.com,1999:blog-7912000584263664000.post-41417250609279107262021-03-16T12:37:00.000-04:002021-03-16T12:37:32.537-04:00Automating Cloud IPAM by Example<p>Automation is a hot topic within IT organizations these days, as well it should be. Automation offers tangible benefits in terms of reducing costs, increasing agility, diminishing manual efforts and minimizing human errors while performing a process. I recommend considering IP address management (IPAM) tasks within your automation design as I proposed in a <a href="https://ipamworldwide.blogspot.com/2021/03/automate-your-ipam-to-acclerate-it.html" target="_blank">prior post</a>, given IPAM's tentacles menacingly reaching into virtually every IP device initialization, movement or decommissioning process. But how does one go about designing automation?</p><p>Consider that you can automate a process if it consists of a repeatable set of discrete tasks required to perform a function or unit of work. Some tasks may be performed in parallel with others and most tasks require input values provided by or derived from prior tasks to begin. Documenting the tasks required and the sequence or flow of tasks, i.e., as a workflow or flowchart, is a prescribed first step. Once you've laid out the basic flow, identify which organization and systems are responsible for performing, approving and tracking each task. Then determine the set of information required to execute a given task within the flow. Of course this information must be either produced during the execution of the flow or provided as input parameters to the overall flow, so be sure to tabulate the source for each task's input parameters.</p><p>In general, the more tasks, management systems and organizations involved within the workflow, the more complex it is. Sometimes in documenting a flow, one may notice a more expeditious sequence of tasks, which affords a potential side benefit to documenting your processes. Complexity generally results in a longer time to complete the overall workflow and a greater need for overall process coordination. This is especially true when task hand-offs between organizations or process owners within the overall workflow are required. In many cases, these hand-offs have traditionally been conducted manually, communicated via phone, email, or process review meetings as necessary. These forms of communications are typically ad hoc in nature and add additional time and variability to the defined tasks within the workflow, so it's advisable if possible to attain approval from involved parties to the extent possible before initiating the overall workflow to eliminate interruptions and delays.</p><p> Let's consider a simple workflow example to illustrate these concepts: I'd like to automate the provisioning of a subnet from my private address space to my virtual private cloud (VPC) with my public cloud service. Since I'm provisioning a subnet from my own private address space, my IPAM system should be authoritative for the assigned subnet. (This is unlike the case when I instantiate a virtual machine, where typically the cloud service is authoritative for address assignment. The point is to maintain flexibility in defining your workflows). So my basic subnet provisioning flow comprises checking my IPAM system for an available subnet relevant to my address plan, allocating the subnet within my VPC using my cloud provider's console, then synchronizing any cross-referential information such as cloud-assigned metadata for the subnet back in my IPAM system. Sounds simple enough.</p><p>Next, let's drill down one layer and map out these steps along with inputs and outputs as illustrated in the figure below. To begin the process, I need to know where within my VPC I need to provision a subnet and of what type (IPv4/IPv6) and CIDR size. I can login to my IPAM system and determine what subnet block(s) is/are available depending on how your IPAM system represents your cloud address space, e.g., by availability zone (AZ) for AWS. Most Diamond IP customers represent VPCs and AZs (and analogous cloud system structures for other cloud providers) using containers within our IPAM system, IPControl. Navigate to the given container for example and simply click the add child block menu to allocate a block of the desired type and size automatically, or enter the subnet address manually (though this blog is all about automation!).</p><p><br /></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjcVgq_5tekrtDGJndcImO_tHNSIErcAyyZhYb9-jDPhbkdjvVTchoeYG-y-QdV89wz7GfmfIQ-FLcskn4LvqUrzHrsCy4Fv_SHcuygc-Ew-HkB_ZFJZ8QF1l8tu5Iz1RdbWsIRQEHHmKvM/s612/CloudSubnetProv.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="612" data-original-width="390" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjcVgq_5tekrtDGJndcImO_tHNSIErcAyyZhYb9-jDPhbkdjvVTchoeYG-y-QdV89wz7GfmfIQ-FLcskn4LvqUrzHrsCy4Fv_SHcuygc-Ew-HkB_ZFJZ8QF1l8tu5Iz1RdbWsIRQEHHmKvM/s320/CloudSubnetProv.png" /></a></div><br /><p>Once you've identified and reserved the automatically-allocated subnet address, you can swivel to your cloud console and provision the subnet of the given address within the corresponding cloud structure. The cloud system may assign a subnet ID and other meta data for the subnet, so it's a good idea to track this in your IPAM system for cross-referencing purposes. So you can log back into your IPAM system and update the subnet information. The process then completes with the successful provisioning of a subnet of the desired type and size within the cloud system, all tracked in your IPAM system.</p><p>Now that we've mapped out the basic process, another pass with an added layer of detail is likely required to specify individual parameters mapping to system-supported API calls for each step. Once you've documented your workflow to this level, you need to define how to orchestrate the flow, accepting outputs from one system, mapping them into and adding parameters for calls into the next. </p><p>At Diamond IP, we recognize the benefits automation brings, particularly with setting the foundation of your services with IPAM. We can help you automate and orchestrate your IPAM related workflows using our Cloud Automation Appliance's (CAA's) drag-and-drop graphical user interface based on NodeRed. We supply primitives for our API calls as well as those for several public cloud providers that you can drag onto your workflow palette to define your own flows specific to your particular processes. </p><p>You can also install published NodeRed modules to incorporate interfaces and interactions with other systems to expand your automation to other critical IT systems and functions. You can even incorporate base flows into broader flows, automating more complex multi-system flows. This code reuse saves time in creating flows, provides consistency in how flows perform given actions, and reduces maintenance by retaining a single place to apply fixes.</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiRGgQio1pZvVsbEV1xWHMYS179AEdlRgauo7edeKdlUIU36HuJw0pmU28KEAcehzaZey68vCt_uZZZ7hiUrMRO9mRIMKuLTm1RM6kNZNlDg22vib5IpeVh6HwwIezaC-n1i1yG8kzZnen3/s822/CAAutomation.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="524" data-original-width="822" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiRGgQio1pZvVsbEV1xWHMYS179AEdlRgauo7edeKdlUIU36HuJw0pmU28KEAcehzaZey68vCt_uZZZ7hiUrMRO9mRIMKuLTm1RM6kNZNlDg22vib5IpeVh6HwwIezaC-n1i1yG8kzZnen3/s320/CAAutomation.png" width="320" /></a></div><p>This figure represents our simple cloud subnet allocation flow example as managed using our CAA. As you can see, the graphical flow interface maps to our earlier flowchart and is relatively easy to digest, edit, and communicate. We supply several API primitives natively for our IPControl IPAM system as well as for other cloud systems, and we also supply a set of sample workflows you can tweak to your desired flows. Please <a href="mailto:btdiamondip-sales@bt.com?Subject:CAA-Inquiry">contact us</a> for a free demo and to learn more.</p>Tim Rooneyhttp://www.blogger.com/profile/01546393894956325009noreply@blogger.com0tag:blogger.com,1999:blog-7912000584263664000.post-12856140257469536802021-03-08T16:09:00.000-05:002021-03-08T16:09:34.505-05:00Automate Your IPAM to Acclerate IT Service Delivery<p>Automation is among the key motivators for implementing an IP address management (IPAM) system. With the ubiquitous adoption of Internet-based technologies engendering IP networks over which nearly all of your applications communicate, it makes sense to simplify and minimize resource impacts for such networked applications and corresponding support. This IP convergence provides financial, efficiency, and productivity benefits in and of itself, but it also escalates reliance on and ensuing scrutiny of IP network performance, resiliency and integration into key business processes. </p><p>Underpinning this IP convergence is the IPAM foundation. Email, web, application servers need IP addresses and DNS names. User laptops, mobiles, and other devices need IP addresses. Cloud virtual machines or containers need IP addresses and DNS names. Literally every device you need to connect to your network needs an IP address; and if users need to reach it by name, it also needs a DNS name. With no IP address or DNS name, there is no network. Clearly it behooves IT engineers to deploy reliable, performant, and resilient IPAM components to supply IP addresses and DNS names in each of these instances.</p><p>Reliability implies that IPAM be not only available when needed but accurate in its capability. When you need to instantiate of virtual machine on VMware for example, you need to rely on a corresponding IPAM function to be available, yes, but also supply an IP address that is unique and relevant to the subnet on which the virtual machine is provisioned. If you maintain IP address inventory in a spreadsheet, reliability necessitates availability of the spreadsheet owner to open and update the file and that this update process has been performed judiciously so no duplication of IP addresses erroneously results.</p><p>Performance in IPAM components essentially requires that IPAM is not inhibiting or worst case, halting the process underway. For example if my spreadsheet owner happens to be out to lunch or away on business or vacation, will you be able to obtain an IP address and DNS name in a timely fashion to instantiate ten containers within five minutes? Agility is an IT hallmark, particularly in today's multi-cloud world, and IPAM processes provide a key ingredient to achieving agility. Likewise, IPAM resilience is critical to supporting availability of alternative methods, e.g., a secondary spreadsheet owner, in order to perform IPAM functions in the face of an "outage" or unavailability of a necessary component. </p><p>While expression of the spreadsheet-based IPAM technique may be trite, it's illustrative of the requirements for reliability, performance and resilience. Your IPAM system must meet these requirements to facilitate the efficiency, agility and manageability of your diverse network. Use of standard protocols such as DHCP for automating address assignment where relevant, and DNS for name resolution, enable you to use stock reference implementations of these protocols. In auto-configured environments such as in IPv6, IoT or public cloud networks, an IPAM system must provide visibility through various forms of discovery and/or through API-integration during the process, e.g., particularly for cloud instantiations. </p><p>A centralized IPAM system serves as the heart of such a diverse network, enabling consistent and accurate tracking of IP address and DNS assignments. Automated deployment of DHCP and DNS server information to distributed DHCP and DNS servers, appliances or containers streamlines the process, promotes agility, and reduces potential errors in entering common information into multiple systems, e.g., a spreadsheet, DHCP server configuration file and a DNS interface. Use of an IPAM REST API with programmable workflows also embeds foundational IPAM functions within broader IT workflows such as automated server builds, container swarm deployments or virtual machine instantiations. </p><p>By leveraging these protocols and IPAM system capabilities, you can streamline your IP address and DNS name assignment processes across your variegated IP network, streamlining overall service delivery. Inserting these capabilities into your orchestration workflows enables incorporation of the critical IPAM functions within corresponding workflows. IPControl, the IPAM solution from BT's Diamond IP for example includes intra-IPAM automation of IP block management, subnets and DHCP/DNS configurations, and it also provides a full REST API. Our Cloud Automation Appliance (CAA) provides an IPAM orchestration engine which enables you to define inter-system workflows with a drag-and-drop web user interface. We supply several sample workflows for public cloud interfaces such as Azure and AWS, as well as a full suite of IPAM API components that may be simply inserted into your workflows. </p><p>A simple REST call to your CAA can render the provision of a subnet in AWS while updating IPControl or the discovery of resource groups, locations, virtual networks and virtual machine IP addresses from Azure for bootstrapping or synchronizing corresponding IPAM data in IPControl. These sample workflows, components, and user-definable workflows and components facilitate adaptation and automation of IP and DNS assignments in accordance with your network and your methods of operation.</p><p><br /></p>Tim Rooneyhttp://www.blogger.com/profile/01546393894956325009noreply@blogger.com0tag:blogger.com,1999:blog-7912000584263664000.post-23454948461075606562021-02-25T17:04:00.000-05:002021-02-25T17:04:08.297-05:00SD-IPAM for SD-WAN<p>Software-defined wide area networks (SD-WANs) enable
organizations to increase networking efficiencies, improve cloud application performance, centralize provisioning, simplify operations, and reduce costs. Please read my <a href="https://ipamworldwide.blogspot.com/2021/02/what-is-sd-wan.html" rel="nofollow" target="_blank">recent post</a> for an overview of SD-WAN. In this post, we'll discuss the importance of flexible, adaptable and "software-defined" IP address management (IPAM) to fully realize the benefits of SD-WAN and to improve your security posture in the face of multiple Internet breakout points.</p><p>IPAM comprises foundational network services for your IP network, which typically encompasses private
networks, cloud networks, remote access networks, Internet of Thing networks and the Internet. Key IPAM functions
include managing IPv4 and IPv6 address space across this diverse network landscape and requires tracking assigned and available addresses, allocating address blocks,
splitting and joining address blocks as well as moving and freeing up address
blocks and subnets. IPAM includes similar activities for assigning, reserving,
moving, and freeing up individual IP addresses, ranges and pools. Accurate
tracking of IP blocks and individual addresses is critical to preventing
duplicate assignments, erroneous assignments, and assignments that do not
roll-up within your addressing hierarchy.</p><p class="MsoBodyText"><o:p></o:p></p>
<p class="MsoBodyText">Beyond the mechanics of assigning and tracking IP subnets
and individual assignments, managing domain name system (DNS) information for
each IP device allows accessibility by name. DNS enables simpler network
navigation by name instead of IP address and it is instrumental in scaling
cloud-based service chains, which feature a succession of component virtualized
services. The IPAM discipline also enhances network security initiatives, particularly with the larger attack surface of multiple Internet breakouts, in offering secure network services and components as discussed later. Governance
functions such as multi-administrator controls with delegation, reporting and
auditing to track address utilizations and IP address accountability, services
upgrading, among others are also critical.</p><p class="MsoBodyText">In terms of how SD-IPAM can facilitate attainment or furtherance of SD-WAN benefits, let's consider each in turn. In terms of increasing networking efficiencies, SD-WAN seeks to offer better network performance and
therefore improved user experience over traditional routed networks. This
benefit stems from the cross-WAN perspective offered under SD-WAN with a
centralized SD-WAN Controller which monitors the status of SD-routers and
associated links, as opposed to the individual router perspective garnered via
routing protocol updates.</p><p class="MsoNormal"><o:p></o:p></p>
<p class="MsoNormal">The centralized SD-WAN Controller may trigger changes in SD-router
configurations to reshape traffic as necessary in terms of routing, quality of
service, and network selections. Consider that first step in any IP
communications prior to router processing is a DNS query to identify the IP
address mapping to the domain name to which a connection is desired. This
“first hop” in IP communications affords an opportunity to steer IP traffic
according to a device’s proximity to cloud POPs, which in turn improves cloud application performance.<o:p></o:p></p>
<p class="MsoNormal">For example, <a href="https://docs.microsoft.com/en-us/office365/enterprise/office-365-network-connectivity-principles" target="_blank">Microsoft recommends</a> deployment of a local DNS
server in each Internet breakout site in order to resolve the closest
accessibility point to the Microsoft Global Network.
Having resolved the closest Office 365 front end server, the device will
attempt to connect to the corresponding IP address. Thus, IPAM and DNS in
particular arm the application with the closest server location which the
SD-WAN router on site shall route optimally in accordance with deployed
policies. And if your SD-WAN router hosts a virtualization platform such as VMware, KVM or even Docker, you could deploy virtual DNS servers to obviate hardware bloat at each breakout site. <o:p></o:p></p><p class="MsoNormal">Despite such hardware cost savings, deployment of local DNS servers to each site may seem
onerous due to the added administration required to properly
configure each DNS server. Each server must be configured to forward queries
for internal hosts to internal authoritative DNS servers, typically via a physical or virtual private network, while recursing queries to Internet DNS servers to resolve
hosts reachable via the Internet such as cloud applications. A centralized IPAM architecture that mirrors that of SD-WAN in
supporting a centralized perspective on the enterprise’s IP address space and provisioning of distributed
DHCP and DNS servers, vastly simplifies such administration. Centralized
administration enables application of common policies, such as forwarding
to internal DNS servers to any number of distributed DNS servers deployed at
each site.</p>
<div><div id="ftn1"><p class="MsoNormal">An IPAM system integrates IP address planning with DHCP and
DNS configuration so a multi-step operational process is greatly simplified. Organizing IP
address space, subnets, IP assignments, DHCP pools and DNS domain information
together enables single-entry of common data with deployment to distributed
DHCP and DNS services. Integrated discovery features provide a pulse on your private and cloud networks to identify any rogue devices, to verify proper provisioning and to
assure the accuracy of your IPAM repository for network auditing, reporting and
monitoring. Integration of the IP and DNS assignment
during the instantiation of virtualized network functions within and around
SD-WAN streamlines overall network and compute process automation. </p><p class="MsoNormal">Lastly, SD-WAN helps reduce costs in reducing or eliminating the
necessity of utilizing expensive carrier private network services. IPAM helps further reduce costs in integrating IP address, DHCP and DNS processes and automating
these processes in the context of broader cloud, IT and operations initiatives.
Jointly, these software-defined solutions facilitate deployment of agile,
adaptive, and automated IP networks to improve efficiencies and reduce overall
operations costs.</p><p class="MsoNormal">Beyond these SD-WAN benefits which can be furthered with the use of SD-IPAM, DNS security features of SD-IPAM can help address a potential SD-WAN shortcoming: increased attack exposure though multiple Internet breakouts from sites with minimal protections. The deployment of local DNS in the form of hardware, virtualized or containerized DNS services can help improve threat detection and mitigation at these sites. Such DNS services as those offered by BT's Diamond IP portfolio, include integrated malware detection via DNS firewalls, data exfiltration monitoring through DNS tunneling analysis, DNS data authentication with DNSSEC, as well as various distributed denial of service protection mechanisms. Along with firewall protections afforded by your SD-WAN routers and other local resources, Internet attack risks can be recognized and reduced to acceptable levels.</p><p class="MsoNormal">SD-IPAM can help you maximize the benefits of your SD-WAN deployment and centralize management of your foundational IPAM services across your diverse multi-platform, multi-services network and compute infrastructure.</p><p class="MsoNormal"><o:p></o:p></p><p class="MsoNormal"><o:p></o:p></p>
</div>
</div><p class="MsoBodyText"><o:p></o:p></p>Tim Rooneyhttp://www.blogger.com/profile/01546393894956325009noreply@blogger.com0tag:blogger.com,1999:blog-7912000584263664000.post-62950042348706327352021-02-24T16:25:00.002-05:002021-02-25T17:04:56.714-05:00What is SD-WAN?<p>The concept of software-defined networking (SDN) can be traced back to common channel signaling (CCS) technology developed during the 1970's and 1980's for use in telecom networks. The CCS #7 protocol operates via a signaling network independent of the telephony traffic (e.g., bearer) network and provides call setup, routing, release and related functions. In an analogous fashion, SDN decouples the data or bearer plane from the control or signaling plane. As illustrated in Figure 1, the data plane comprises network routing hardware or virtualized network functions while the control plane includes software that “defines” or monitors, manages and reconfigures network routers to achieve optimal performance.</p><p>Software-defined wide area networks (SD-WANs), the WAN component of SDN, enable organizations to partially or entirely supplant private network services such as Multi-Protocol Label Switching (MPLS) in order to improve network performance, centralize provisioning, simplify operations, and reduce costs. These benefits can be realized via dynamic path selection for load balancing and redundancy as well as support for multiple network interfaces, e.g., for the Internet, VPN, 5G and MPLS.</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiOyJXydTYtT04e0SKjwkYgl8U313MoJMf7FFWA7vqlQwyuV5dXfXhEX9_bmc5qh4sRblNrTj14MAJ2ZP59y6YLyfXm-M8RUy3mXJoyX_kQG2IVhe83ynzRE9GQ3Lcbu4vVBFva1IWOFOWN/s668/SDWANPlanes.png" style="margin-left: 1em; margin-right: 1em;"><img alt="SDWAN data and control planes" border="0" data-original-height="393" data-original-width="668" height="188" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiOyJXydTYtT04e0SKjwkYgl8U313MoJMf7FFWA7vqlQwyuV5dXfXhEX9_bmc5qh4sRblNrTj14MAJ2ZP59y6YLyfXm-M8RUy3mXJoyX_kQG2IVhe83ynzRE9GQ3Lcbu4vVBFva1IWOFOWN/w320-h188/SDWANPlanes.png" title="SDWAN data and control planes" width="320" /></a></div><div style="text-align: center;">Figure 1: SDWAN control and data planes</div><p style="text-align: left;">The SD-WAN Controller is an entity within the control plane which performs the monitoring of network traffic and enables the dynamic configuration of software-defined routers (SD-routers) to enable routing over various networks with corresponding adjustments to application traffic prioritization, treatment and routing as necessary. To illustrate a benefit of the SD-WAN architecture, let’s contrast it to the traditional private WAN with a single Internet connection. In the traditional architecture, as illustrated on the left side of Figure 2, internal enterprise sites interconnect via a private network such as MPLS. Access to the Internet is funneled through one or just a few Internet egress points, secured via demilitarized zone (DMZ) infrastructure. One major benefit of this approach is a limited attack surface from which Internet-based attacks may target. However, it suffers from forcing enterprise devices from sites geographically dispersed, perhaps globally, to transit the enterprise network to the DMZ then to the intended Internet destination.</p><div class="separator" style="clear: both; text-align: center;"><br /></div><p style="text-align: center;"></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjtOUtaS2bbM8vsohrwKsF2SBFfZuDK-a3pqbn_UxTFjzQeTFuV4CY2Ydf3BYuY1ciYjfIcZyACrcmDg-Kj11iUNkSkPbSNAI1367ixPfn-PZ7vcZ6K9Pm_LU8z3WzmHWDXxeKUxNs9lYdD/s938/WANvsSDWAN.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="389" data-original-width="938" height="166" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjtOUtaS2bbM8vsohrwKsF2SBFfZuDK-a3pqbn_UxTFjzQeTFuV4CY2Ydf3BYuY1ciYjfIcZyACrcmDg-Kj11iUNkSkPbSNAI1367ixPfn-PZ7vcZ6K9Pm_LU8z3WzmHWDXxeKUxNs9lYdD/w400-h166/WANvsSDWAN.png" width="400" /></a></div><div style="text-align: center;">Figure 2: Traditional WAN with Single Internet Egress (left) and SDWAN with Internet Breakout (right)</div><p></p><p style="text-align: left;">As illustrated on the left of Figure 2, Internet traffic is routed to the destination nearest the DMZ, e.g. Cloud POP Y in the figure, not necessarily the originating device. Thus, accessing an Internet site physically located down the street could traverse the globe to route via the DMZ egress. This is particularly menacing when accessing enterprise applications hosted in the cloud where application traffic interfaces via the cloud point of presence (POP) closest to the DMZ and not the application user, potentially introducing excessive latencies.</p><div><p class="MsoBodyText">Contrast this approach with the right side of Figure 2, where local Internet access
has been provisioned to each site to support direct Internet access from each site.
While we illustrate only the Internet “cloud” on the right of Figure 2, in practice two or
more networks may be accessible from all or selected sites to enable
multi-network access for particular connections or connection types. The local
Internet “breakout” illustrated on the right side of Figure 2 accentuates the ability of each
site to be routed to Internet destinations in an optimal fashion. This architecture enables each site to connect to the
closest (in terms of routing) Internet-based destination, including cloud POPs,
affording better application performance thanks to lower roundtrip time and
latency than the traditional approach. The downside is a broader
Internet-facing attack surface, which requires more protection and vigilance
from a network security perspective.</p><p class="MsoBodyText"><o:p></o:p></p>While advantages and disadvantages can vary based on deployment, the key advantages of SDWAN include:</div><div><ul style="text-align: left;"><li>Network cost savings through the use of multiple network interfaces, reducing reliance on expensive private network services like MPLS.</li><li>Cloud adaptable with application performance through optimal routing among multiple interface options including Internet breakout</li><li>Flexibility in deployment enabling evolution from WAN to SDWAN and the addition or removal of selected network interfaces over time</li><li>Increased resiliency in the face of network outages to reroute among multiple networks</li><li>Improved device utilization efficiency with the use of orchestration for virtualized network functions or containers on some SDWAN routers enables deployment of additional network services such as DNS locally without additional hardware requirements (see my <a href="https://ipamworldwide.blogspot.com/2021/02/sd-ipam-for-sd-wan.html" target="_blank">companion post</a> on SD-IPAM for SD-WAN)</li></ul><div>Some potential disadvantages include</div><div><ul style="text-align: left;"><li>Larger attack surface with more Internet access points, so security policies must be enacted across all Internet breakout points</li><li>Higher cost of network access of each network type across multiple sites as well as SD-WAN routers though this can be offset and paid back through network cost savings</li><li>While SD-WAN routers generally provide improved monitoring and reporting, staff need to remain vigilant and proactively manage; e.g., staff training required.</li></ul></div><div>Use of SD-WAN managed services such as <a href="https://www.globalservices.bt.com/en/solutions/products/connect-cisco-sd-wan" target="_blank">those offered by BT</a> can offset most of these disadvantages by offering zero-touch provisioning, ongoing monitoring and management, and additional security surveillance and services. </div></div><div><br /></div>Tim Rooneyhttp://www.blogger.com/profile/01546393894956325009noreply@blogger.com0tag:blogger.com,1999:blog-7912000584263664000.post-61579542427993597722021-01-19T13:06:00.000-05:002021-01-19T13:06:28.499-05:00Applying ITIL4 to IP address management<p> The discipline of network management affords innumerable technical and business benefits to organizations via the centralization of control, monitoring, and provisioning of distributed network elements such as routers and application or services databases. These benefits include holistic management of the entire network from a centralized point where appropriate resources and expertise can be leveraged for troubleshooting, resolution, and escalation. This pan-network approach lends itself well to supporting structured network change control procedures and is even more crucial today with enterprise networks expanding into clouds, IoT subnetworks, and mobile networks.</p><p>Because IP addresses and associated DHCP and DNS functions are foundational to IT services and applications running over an IP network, these functions must be prudently managed, much as other critical network infrastructure elements are managed. The most commonly applied network management approach is that of the FCAPS model from a functional perspective and ITIL® from a service management perspective. </p><p>To fully understand and appreciate ITIL, let’s start first with a quick review of the International Telecommunications Union (ITU) network management standard FCAPS, which is an acronym for the five major management functions: Fault, Configuration, Accounting, Performance and Security. These five functions should be considered when implementing a network management architecture, whether it's for a service provider or enterprise environment. FCAPS is specified in the ITU’s M.3400-series, which deals with telecommunications network management. </p><p></p><ul style="text-align: left;"><li>Fault management deals with alarming and detection of faults within the various elements of the network and the localization or identification of the root cause of those faults, as well as the correction, repair, testing and trouble-reporting of faults.</li><li>Configuration management involves planning, installing and provisioning of a new network element, as well as adding in customer related data. Provisioning of a new customer, for example, on a telecommunications-type service would impact the configuration management function. </li><li>Accounting management addresses the collection of information that can be used, perhaps by a billing or usage management system. As such, the accounting management function measures the use of the network and associated resource utilization, which can be used to generate goals for evolving and improve network services. </li><li>Performance management encompasses the evaluation and reporting of the behavior and effectiveness of network equipment. This includes measurement of capacity and quality of transmissions, usage of network elements and CPU utilization. In a nutshell, it helps make sure the network is running on all cylinders. </li><li>Security management deals with the prevention, detection and containment of any security issues or concerns related to your network, computing and applications infrastructure. It also includes an audit logging capability in order to troubleshoot or analyze any violations or to detect security violations. </li></ul><p></p><div><div>FCAPS was developed as a standard for management of telecommunications service providers’ networks. ITIL, formerly known as the Information Technology Infrastructure Library, is a documented set of best practices for use by an IT organization desiring to manage, monitor, and continually improve IT services provided to the enterprise organization. ITIL was originally developed by the U.K. Office of Government and Commerce, and is now managed by Axelos, a joint venture company created by the Cabinet Office of Her Majesty’s Government in the UK and Capita, plc. Its IT-service oriented approach has been deployed by a number of organizations. The most common drivers for ITIL implementation include:</div><div><ul style="text-align: left;"><li>Cost reduction of IT services delivery to the organization</li><li>IT service level consistency and improvements</li><li>Risk management through disciplined planning and evaluation of potential service-affecting changes</li><li>Efficiencies in utilizing documented processes and continual improvement</li></ul></div><div>ITIL 4, the latest version, was launched in February, 2019 as an evolution of version 3. There are many similarities between the two versions, but the major changes introduced in ITIL 4 include the following:</div><div style="text-align: left;"><ul style="text-align: left;"><li>The service value chain concept has replaced the ITIL 3 service lifecycle in order to loosen the implication of an ordered serial process and to more accurately reflect the use of service value chain activities alone or in conjunction with others in no specific order to provide value.</li><li>The concept of how value is created has evolved from that of being created by IT alone (service provider) to that of being jointly created by the service provider and the service consumer, which in turn comprises the customer or services definer, user of the service and sponsor or budget authorizer.</li><li>The concept of “process” has been broadened to that of “practice”, which defines a broader perspective and accounts for people, partners, technology and processes. </li></ul></div></div><div><div>Designed as an evolution, ITIL 4 seeks to broaden the perspective of IT services management to broader organizational goals and constituents, while building upon most of the foundational concepts and processes specified in prior ITIL versions. ITIL best practices serve as an industry benchmark against which you can measure the effectiveness of your IT practices and plan for improvements.</div><div><br /></div><div>Whether you’re comfortable with the legacy FCAPS model or the enterprise-focused ITIL service management approach, the institution of a disciplined and documented approach to performing IT functions can help save time and money. Performing service delivery functions in a consistent, repeatable manner yields predictable and measurable service levels. These service levels can then provide a measure of IT service expectations for the end user community and enable IT to meet or exceed such expectations regularly, maximizing efficiency and productivity.</div><div><br /></div><div>As IT services increasingly require IP-based applications and services, the reliance on an effectively managed IP network grows. It follows that IP address management functions should be on the forefront when implementing a disciplined IT management scheme. Read our white paper on Applying ITIL Best Practice Principles to IPAM for more details and for examples of how ITIL practices apply to IPAM. Contact me or your BT representative for your free copy.</div></div><div><br /></div>Tim Rooneyhttp://www.blogger.com/profile/01546393894956325009noreply@blogger.com0tag:blogger.com,1999:blog-7912000584263664000.post-75598488240265663042020-11-13T11:47:00.001-05:002020-11-13T12:05:30.980-05:00Another reason you should implement DNSSEC now<p>Researchers from the University of California and Tsinghua University in China have <a href="https://dl.acm.org/doi/10.1145/3372297.3417280" rel="nofollow" target="_blank">published </a>discovery of a new form of DNS cache poisoning attack. This form of attack leverages "side channels" through use of the Internet Control Message Protocol (ICMP) to improve the likelihood of attack success by identifying the subset of source UDP ports actually used by a recursive server when issuing queries. Confining this pool of randomized ports helps reduce the universe of port numbers the attacker can try when attempting to emulate a proper query response. </p><p>Source port and DNS transaction identifier randomization has been the recommended mitigation approaches against cache poisoning attacks, even for more nefarious Kaminsky-discovered attacks. However, this use of side channels reduces the robustness of source port randomization mitigation. Of course, DNS security extensions (DNSSEC) remains the only definitive means to mitigate cache poisoning attacks, including this new variant. </p><p>But let's start at the beginning: DNS resolvers, forwarders and recursive servers (generally "resolvers") maintain a cache
of resolved resource records to improve name resolution performance by obviating repeated lookups for information recently queried. If an attacker succeeds in corrupting a resolver's cache, the
corrupted information may be provided to several users requesting the same or
similar domain name information. Corrupting the cache requires an attacker to
provide a seemingly legitimate query answer albeit with falsified resolution information
in part or in total.</p><p>These types of attacks are generally conducted as shown in the figure below where an attacker appears to the recursive server as the legitimate authoritative server to which it issued the query. In the various forms of this attack, ultimately the attacker attempts to corrupt the cache of the recursive DNS server, e.g., by pointing the resolution of a legitimate and even popular web or server address to a server operated by the attacker. The falsified resolution data is returned to the originator of the query and is also returned to other resolvers querying for this information while the corrupted information resides in cache, i.e., for the duration of the TTL. This has the effect of hijacking potentially several resolvers and hence applications to incorrect destinations, e.g., web sites.</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj0xgLounVxg_RpZWeZYYlDZHBxGYN10hHWNqUlCcKBQMXao24GKAHTJ401Xt132lw1WgTMsgcBBtS_4e-SFaUmNYVonvCy6g2lbGrW4YsiNF2u1eiB53XO7OBIXHPAOkpUussWxQOwJdF-/s656/Figure+4-6.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="246" data-original-width="656" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj0xgLounVxg_RpZWeZYYlDZHBxGYN10hHWNqUlCcKBQMXao24GKAHTJ401Xt132lw1WgTMsgcBBtS_4e-SFaUmNYVonvCy6g2lbGrW4YsiNF2u1eiB53XO7OBIXHPAOkpUussWxQOwJdF-/s320/Figure+4-6.png" width="320" /></a></div><br /><p>To corrupt the cache, the DNS query response from the attacker must reach the server before the legitimate response and map to an outstanding query for which the recursive server is awaiting a response. The server will map a received answer to a previously issued query by matching the following fields in the response:</p><p></p><ul style="text-align: left;"><li>The source IP address of the response maps to the destination IP address of the query and the destination IP address matches the address of this server.</li><li>The destination port of the response with the source port of the query and the answer’s source port is 53.</li><li>The DNS transaction ID within the DNS header matches on both the query and the response</li><li>The DNS Qname, Qclass and Qtype in the question section matches on both the query and the response.</li><li>The domain names in the Authority and Additional sections of the response must fall within the same domain branch as the Qname. This is known as the bailiwick check.</li></ul><p></p><div>The DNS server will accept the first matching answer it receives, cache it and respond to the querying user. If the attacker can match the parameters with an answer that arrives before the legitimate answer from the authoritative name server, he or she will have succeeded in poisoning the cache with an answer that will be provided to other clients querying similar information. As mentioned in the opening, this side channel attack helps reduce the span of candidate UDP ports used by the resolver, and therefore reduces the number of unique parameter combinations an attacker must use to guess correctly.</div><div><br /></div><div>You can turn off ICMP, reduce query timeouts, even use qname case checking, but the only definitive solution to this attack is DNSSEC. When responses are signed and the resolver validates the signature using the DNSSEC chain of trust, the resolver is assured that the response was published by the authoritative zone operator and that the response was not modified en route. And these days, implementing DNSSEC validation is really easy. In fact, most commercial distributions of DNS recursive servers support DNSSEC validation out of the box. This includes provision of the root zone public key and support for automated detection and updating of changed root keys. Such automation provides virtually hands-free implementation and ongoing maintenance of DNSSEC validation. </div><div><br /></div><div>Of course, your recursive servers can only validate DNSSEC-signed resolution data, and herein lies the rub. Unfortunately, while 85% of US government zones are signed, only 7% of university zones and about 4% of industry zones are signed according to <a href="https://usgv6-deploymon.antd.nist.gov/snap-all.html" rel="nofollow" target="_blank">NIST estimates</a>. Thus, the majority of non-US government zones remains unsigned as of today. In terms of DNSSEC validating resolvers, <a href="https://stats.labs.apnic.net/dnssec/XA?hc=XA&hx=0&hv=1&hp=1&hr=1&w=15" rel="nofollow" target="_blank">APNIC measurements</a> indicate about 25% of DNS resolvers support DNSSEC validation. </div><div><br /></div><div>While signing zones is more complicated than validating signatures, at least in terms of implementation and management, the process has gotten a lot easier for most leading implementations. Many implementations support automated key generation and rollover but often some manual intervention is required, especially when rolling key signing keys (KSKs). Even fully automated authoritative signing servers including BT's require some effort to link the chain of trust, though support of CDS and CDNSKEY records by both parent and child can help automate this process as well. </div><div><br /></div><div>To learn more about this attack, what defenses you can deploy, how DNSSEC can help and even how BT's solutions can help ease implementation, please contact me via email or comment.</div><p class="MsoNormal"><o:p></o:p></p>Tim Rooneyhttp://www.blogger.com/profile/01546393894956325009noreply@blogger.com0tag:blogger.com,1999:blog-7912000584263664000.post-65290757044158084942020-09-10T15:28:00.000-04:002020-09-10T15:28:24.683-04:00Has IPv6 Peaked?<p>Several articles have attempted to address the topic of IPv6 Internet penetration over the years, including some of mine, based on metrics compiled and published by <a href="https://www.google.com/intl/en/ipv6/statistics.html" rel="nofollow" target="_blank">google </a>in terms of the percentage of IPv6 connection attempts to their websites with respect to total attempts. Certainly this is but one metric of IPv6 end user devices and a convenient one at that. Over time I've fitted trend lines to these data points in an attempt to gauge the present and predict future penetration growth. Let's take a look at how those trends and forecasts have changed with increasing data points over time. We'll examine these cases with the application of a third order polynomial trend line in each scenario for consistency.</p><p>The following chart illustrates three such trends and predictions at roughly two year intervals. A dotted vertical line for each prediction indicates the point in time when the projection of the corresponding matching color was made. For our first prediction in June, 2016, made at the point in time shown by the leftmost vertical line in the chart, the trend line curved up steeply. Had that trend proven true, we'd be at 40% penetration right now and would reach 50% within a year. Two years later, in July, 2018 as shown in the chart at the point of the middle vertical line, the trend exuded a less optimistic path to IPv6 domination as the slope damped downward to a more linearly oriented growth trajectory, not eclipsing 40% penetration until February, 2021 and 50% fourteen months later.</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiff7fX6yDtJ2HfvUxTtjvT3FU3QZK7YZ5GTUGD4WSVmDEX_AzC-bhT5-ci8GAiwq3PARNjCGX1mpqGg3Xp14V99h2HaLJhcQjV7iE3GNP3AlFjaPlK0HlinuI3bFV9SSKiuiRapFGj25d_/s609/Sep2020GoogIPv6.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="446" data-original-width="609" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiff7fX6yDtJ2HfvUxTtjvT3FU3QZK7YZ5GTUGD4WSVmDEX_AzC-bhT5-ci8GAiwq3PARNjCGX1mpqGg3Xp14V99h2HaLJhcQjV7iE3GNP3AlFjaPlK0HlinuI3bFV9SSKiuiRapFGj25d_/s320/Sep2020GoogIPv6.png" width="320" /></a></div><br /><p><br /></p><p>Today's trend fitting of the data, shown at the point of the rightmost vertical line, has again diminished in slope and even hints the appearance of a leveling off. In fact, if we take the first derivative of the trend equation, graphed in the figure below, we can see that the rate of change has in fact peaked and is now diminishing. In fact, according to this formulation, the inflection point occurred in August, 2018.</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiZQxBNco_Etbl4eJIHLxlEk1A1LyeQ9D4-FGKKmPpOcVGcAi_Navi3BpXspFiqtAEGIK87qJt7iPR0MJoAznZoqOKWp5GiL9kXy0N9COPyb2UuondFfcNLNGSUsYfxx7L524XcqJ9Xh4xB/s606/Sep2020IPv6Growth.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="288" data-original-width="606" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiZQxBNco_Etbl4eJIHLxlEk1A1LyeQ9D4-FGKKmPpOcVGcAi_Navi3BpXspFiqtAEGIK87qJt7iPR0MJoAznZoqOKWp5GiL9kXy0N9COPyb2UuondFfcNLNGSUsYfxx7L524XcqJ9Xh4xB/s320/Sep2020IPv6Growth.png" width="320" /></a></div><br /><p>Now just because we can fit a curve to google's observed data, obviously doesn't mean we can make definitive predictions, as made obvious by our prior attempts over the years. But it does call to question, at what point will IPv6 be "fully deployed"? Initial enthusiasm for the new Internet Protocol and the realization that IPv4 address space faced exhaustion certainly sparked bold predictions of total migration of IPv4 to IPv6 over only a few years. But countermeasures such as network address translators (NATs) of various flavors helped large organizations, namely service providers to better utilize their IPv4 space, and as some organizations such as cloud providers outright purchased IPv4 space, the fervor for IPv4's imminent demise faded.</p><p>Despite the IETF's attempts to declare IPv6 as "the" Internet Protocol and IPv4 as the legacy protocol to encourage deployment of IPv6, hopes of rapid, full migration faded to acknowledgment of a long tail for IPv4 and of IPv4-IPv6 co-existence. Unlike other technology "migrations" such as from prior generation mobile phones to smart phones, where the perceived benefits included new and desirable functionality for both consumers and service providers at a worthy cost, belief in a comparable leap in benefits of moving to IPv6 is not universally held. </p><p>Most large service providers have IPv6 fully deployed within their networks, but given the incompatibility of IPv4 and IPv6, they've leveraged the aforementioned NATs or similar capabilities to enable their subscribers to access the dual protocol Internet. But for many enterprises, perceived IPv6 benefits do not surpass the cost and effort to deploy universally. These costs include the effort to validate infrastructure (compute, networking, applications) for IPv6 compatibility, managing the implementation, training of engineers and support personnel, and ongoing management, security and user support. Key benefits include improved mobility support, native Internet of Things (IoT) support over lossy networks, and a plentiful address supply. </p><p>The chief benefit in my mind however is the ability to serve the whole Internet from your Internet presence; if google is currently seeing one-third of users attempting to connect with IPv6, you may be too. Thus I've been advocating for some time deployment of IPv6 alongside your IPv4 at least within your Internet facing services, e.g., your web services, email, DNS and other Internet-accessible applications. </p><p>A dual stack Internet presence enables your organization to serve the full Internet without having to fully deploy IPv6 within your enterprise network. This approach offers savings related to confining the deployment scope and reducing the end user support costs since end users would still use IPv4 internally. In terms of adoption of such server-side Internet support, Eric Vyncke's <a href="https://www.vyncke.org/ipv6status/" rel="nofollow" target="_blank">website </a>publishes measurements which indicate about 27% of Alexa sites have implemented IPv6 in terms of website and email reachability. </p><p>As for the question of "are we done yet?," the answer is "not yet." While the rate of IPv6 penetration has slowed, growth is still positive and equilibrium may yield a roughly 50/50 split of IPv4 and IPv6 connections. But IPv6 ubiquity or even dominance won't happen until major device, networking equipment, cloud, and content network providers support only IPv6, necessitating organizational support. When all business communications may ensue using IPv6 bidirectionally and ubiquitously, only then may IPv4 be decommissioned. Until that time, we will likely see IPv6 penetration continue to slowly and steadily rise. So if you haven't deployed IPv6, I'd recommend analyzing your effort and cost to do so within your Internet presence initially.</p><p>If you're new to IPv6 and would like to learn more about it, I invite you to access our <a href="http://tinyurl.com/ipv6-tools" rel="nofollow" target="_blank">free online tools</a> to help you familiarize yourself with business drivers for IPv6, your return on investment (ROI) for deploying IPv6, as well as IPv6 addressing and subnetting. These tools can help you understand the implications both of deploying IPv6 and of not deploying in terms of upside opportunity versus cost.</p>Tim Rooneyhttp://www.blogger.com/profile/01546393894956325009noreply@blogger.com0tag:blogger.com,1999:blog-7912000584263664000.post-43306127752843122322020-04-15T12:13:00.000-04:002020-04-15T12:13:09.687-04:00Keep DNS in mind when planning your office re-openingIt's hard enough dealing with the possibility that during weekends members of your network user community use their devices to browse the Internet off-network then return to office to reconnect to your enterprise network with devices unwittingly infected with malware. With many localities operating under extended stay-at-home mandates in place to support flattening the COVID-19 infection curve, the threat of malware infestation is exacerbated, not only by the lengthy duration but as users adapt and become comfortable with work-at-home routines, they may become overly casual and less vigilant to threats.<br />
<br />
The <a href="https://www.av-test.org/en/statistics/malware/" rel="nofollow" target="_blank">AV-Test Institute</a>, an independent IT security research institute, has identified over one billion malware programs in existence. And when it comes to malware, ransomware, and other undesirable software programs potentially impacting the security of your network and your users, there’s good news and there’s bad news. The good news is that most of these programs are identifiable and can be mitigated with currency of anti-virus software and firewalls within your network. So it’s imperative that you keep anti-virus software and firewall software up-to-date.<br />
<br />
Now for the bad news: the AV-Test Institute also claims to register over 350,000 new malicious programs, or malware, and potentially unwanted applications <i>per day</i>. With such a vigorous rate of productivity, it is exceptionally challenging for anti-virus and firewall software vendors to remain current in order to detect and mitigate all new malware.<br />
<br />
While no one or even two point solutions like anti-virus and firewalls offer a perfect defense, the use of several solutions, each perhaps examining different aspects of the cyber kill chain, the way malware infests, communicates and spreads, can in combination offer a less imperfect defense. This is the premise of a defense in depth strategy where the whole solution truly is greater than the sum of its constituent solution parts. So what additional controls can you add to anti-virus and firewalls to more effectively detect and prevent malware infestation?<br />
<br />
Training end users is certainly a key ingredient in your defensive strategy against malware penetration, as many forms of malware infiltrate your network through clicked links, opened attachments, software downloads and related user-triggered means. This is equally true whether working from the office or from home. But from a technology perspective, there is one additional major defensive layer you can implement rather easily to improve your chances of detecting new malware and stopping it from spreading or damaging your network and computing infrastructure. And that is to arm your DNS or domain name servers with firewall capability.<br />
<br />
Everyone uses DNS and every network has DNS servers. DNS is a critical component of Internet infrastructure that frankly makes the Internet usable for you and me. That’s because we find it easier to remember names of websites, not numbers, so DNS provides this convenient lookup and translation feature so we can connect to sites by name while our computers can connect by numerical addresses.<br />
<br />
When we connect on the Internet, we type or click a name on our device, then our device initiates this first step and looks up the name in DNS. As the second step, our device takes the answer from DNS and attempts to connect to the corresponding address typically through an enterprise firewall. The third step entails our device receiving the response over the connection and presenting it to the user.<br />
<br />
If we consider how most malware adapts to the environment into which it has installed itself, the malicious software will often attempt to communicate with the malware author over the Internet, to the author’s website or file server. Like your devices, the first step for malware typically entails a DNS lookup to translate the malware author’s website address into its corresponding IP address that it uses to communicate over the Internet. Then the malware can make the connection to the IP address returned from DNS, download new software, upload stolen information, or otherwise receive nefarious instructions over that connection.<br />
<br />
Most enterprises only address steps two and three in this Internet connection process. Network firewalls provide protection during step two to examine and filter connection traffic to detect and potentially block suspected malware traffic. Anti-virus software can be used in step three to scan received content for malicious software and take appropriate actions. But many enterprises miss an important detection point at step one, at the DNS layer.<br />
<br />
With the implementation of a DNS firewall, you can detect malware domain lookups and stop malware before it progresses to the connection and data transfer phases. A DNS firewall can examine not only the name being looked up, but also the answer received, the answering DNS server address or name, and more. Based on the examination of the query and response, DNS firewall policies can be defined to dictate whether to drop the response, respond with “not found,” or provide an alternative response answer to redirect the querier to a mitigation server for example.<br />
<br />
And DNS firewall functionality is natively supported by many reference implementations including those from ISC/BIND, PowerDNS, KnotDNS and many vendor products such as Diamond IP. Microsoft Windows Server 2016 and 2019 requires installation of a separate utility. Several service providers including Diamond IP also offer DNS firewall feeds which use standard DNS protocol provide real time updates of blocklists and whitelists for domains and related information. So if the DNS servers in your network already support DNS firewall functionality, there’s no need to purchase new hardware; all you have to do is subscribe to a DNS firewall service to enable your DNS firewall and receive timely updates.<br />
<br />
The type of blocking information you receive from a DNS firewall service is different from that received for your in-band data firewalls. And that’s a good thing because it widens your malware-snagging net so to speak, by looking at more criteria for a given connection in order to better ascertain a given connection attempt as malicious or not based on DNS, in-band data, and device level controls. A DNS firewall is a simple, affordable solution to increasing the layers of your overall defense in depth strategy to improve your chances of detecting and mitigating malware in your environment, in the face of 350,000 malware updates per day.<br />
<br />
As we look forward to the loosening of social distancing guidelines, let us look forward with hope while retaining vigilance upon the safety and health of our communities and each other. And as we map out plans to re-open our offices to workers, many of whom have been working from home for an extended period, let us also retain vigilance upon the protection of our networks. Consider deepening your malware threat defenses with a DNS firewall implementation. As always please contact me if you have any questions or to learn more.<br />
<div>
<br /></div>
Tim Rooneyhttp://www.blogger.com/profile/01546393894956325009noreply@blogger.com0tag:blogger.com,1999:blog-7912000584263664000.post-84897810550783478422020-03-31T15:08:00.000-04:002020-03-31T15:09:10.499-04:00Covid-19 and IPv6 UsageWith increasing numbers of white collar workers hunkering down within their homes across the globe over the past couple of weeks, full time working from home is becoming the norm - at least while Corona virus social distancing measures are in place. I was curious how this shift in worker locale might impact IPv6 usage around the world. One popular benchmark is Google's IPv6 statistics, which measures the percentage of IPv6 browser connections to its websites.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgaHDj3qf-uocHVveDxXk7BoQAEUTkaRJC387bZRPkGKf2ZyQ7hX6nOYbSWPgHA48vsfy17c_THS8kMXuTgYZQ9b0iQwLy6TZ5soUhYhO5F_Cc3STwGh46xEBRATG6L3RQQ59z4z4RaVTlU/s1600/GoogCorona.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="462" data-original-width="695" height="212" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgaHDj3qf-uocHVveDxXk7BoQAEUTkaRJC387bZRPkGKf2ZyQ7hX6nOYbSWPgHA48vsfy17c_THS8kMXuTgYZQ9b0iQwLy6TZ5soUhYhO5F_Cc3STwGh46xEBRATG6L3RQQ59z4z4RaVTlU/s320/GoogCorona.png" width="320" /></a></div>
<div style="text-align: center;">
Images from <a href="https://www.google.com/intl/en/ipv6/statistics.html">https://www.google.com/intl/en/ipv6/statistics.html</a></div>
<div style="text-align: center;">
<br /></div>
Over the 12+ years of data points within the graph, the data has exhibited a periodicity with a relative spike on weekend days and nominally lower percentage values during workdays. This leads one to surmise that remote users, when at home, more often connect via IPv6 than when in the office. This theory is supported by the sustained higher percentages of IPv6 utilization during the Christmas holidays in late December and now during the general Corona virus lockdown with the variance between weekday and weekend day percentages narrowing as you can see in the graph above.<br />
<br />
It's too early to tell if this current remote work environment will cause a rise in the overall IPv6 proportion of Internet users. But looking back further throughout the entire data set, the general trend conveys a gentle rise up to about one-third of Internet users by the end of 2020 based on a third-order trend line shown in the figure below.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhZ0BoNxXg-ncWjHjD_tG7B22wnEWNkgdQ3FcqwKYFLgJfzSAURqmg32svMdBKVWR4Ov1UB1EhEsx0N1R5XyETYMEw1mZoO6I3luJ5rLhPu2GrNZ4qLTswfqo8IxTKhtXXspshF0WGW71ZI/s1600/GoogleDataTrend0320.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="446" data-original-width="842" height="169" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhZ0BoNxXg-ncWjHjD_tG7B22wnEWNkgdQ3FcqwKYFLgJfzSAURqmg32svMdBKVWR4Ov1UB1EhEsx0N1R5XyETYMEw1mZoO6I3luJ5rLhPu2GrNZ4qLTswfqo8IxTKhtXXspshF0WGW71ZI/s320/GoogleDataTrend0320.png" width="320" /></a></div>
<br />
While this chart illustrates the global Internet penetration of IPv6, Google's per-country statistics indicate that many major western economies are well above this average; i.e., the U.K. is in the low 30% range, the U.S. and France are in the low 40% range and Germany is already above 50%. While no one knows for sure how long remote working will be required and even if it will become semi-normal policy after social distancing measures have been relaxed, the uptick in everyday IPv6 users buoyed by an observed gradual increase over time validates the wisdom of deploying IPv6 to prepare for this rising tide if you have not already done so.<br />
<br />
<br />
<br />Tim Rooneyhttp://www.blogger.com/profile/01546393894956325009noreply@blogger.com0tag:blogger.com,1999:blog-7912000584263664000.post-86106674698558666062019-03-13T09:26:00.000-04:002019-03-13T09:26:33.904-04:00Enabling cloud network automationI've never liked the term "enablement." It's one of those superfluous terms like "incentivize" and "irregardless" likely coined by corporate sycophants either to render the otherwise mundane more alluring or in ignorance of the existence of shorter formed synonyms. So instead of discussing "automating cloud network enablement," we'll cover"enabling cloud network automation."<br />
<br />
Moving beyond my introductory digression, i.e., back to the mundane, that is the concept of the cloud which promises several benefits to IT organizations. The cloud offers the ability to leverage infrastructure, platforms and applications to use when needed, for as long as needed, and to pay only for what they used and for how long. This ability to grow and shrink computing, application or infrastructure capacity on demand provides the elasticity enterprises need to support demand surges, new developments, business continuity and much more.<br />
<br />
Elasticity frees enterprises from overspending on in-house IT capacity in terms of computing hardware and appliances, requisite power, real estate, and cooling, to size computing resources for the largest forecasted capacity, which may only be required a small percentage of the time. The cloud enables an organization to size in-house computing resources to nominal capacity and to cloud-burst computing capacity as required on demand.<br />
<br />
Dynamically sizing computing capacity is great, but what good is it if it is not accessible by users via your networks? By extending your enterprise network via virtual private networks, VPNs, to your virtual private clouds, VPCs, within a single or several public cloud providers, you can elastically expand your enterprise network as you expand your computing resources. Once your VPNs and VPCs are setup, the critical step to rendering newly instantiated virtualized network functions accessible is the assignment of IP addresses and DNS names to each one respectively.<br />
<br />
By assigning each virtualized resource an IP address within the subnets assigned to your VPCs, you can effectively expand your network and computing resources on demand. And given the expectancy of cloud for rapid response times for instantiating this capacity, you need to have the ability to instantly assign IPs and names. Taking the time to lookup subnets and available IP addresses in a spreadsheet just won’t do. You need to identify and assign an IP address and name during the very process of instantiation to retain the cloud benefits of agility and scale.<br />
<br />
You can achieve this level of responsiveness by incorporating your IP address management, or IPAM system into the process. When your cloud provisioning system such as Ansible, Chef, Puppet, and so on, initiates a virtualized resource provisioning request, leverage the cloud automation capabilities of your IPAM solution to enable the automated flow of identifying available IP addresses for the VPC in question, along with associated names, assigning the addresses and names in DNS, then applying this information too in the instantiation of respective virtualized network functions.<br />
<br />
Incorporating IP and name assignment into the instantiation process affords you the ability to elastically expand network-reachable computing capacity on demand. Automating the IP address and name assignment process reduces manual effort, saves costs, and virtually eliminates duplicate IP assignments in your VPCs.<br />
<br />
The elimination of duplicate assignments however requires your IPAM system to maintain an up-to-date IP inventory. Some cloud systems may hold over an IP address from a destroyed virtualized network function and disallow reassignment for a few minutes. Your IPAM system needs to reflect this in order to prevent the assignment of a temporarily unavailable address, which could result in a failed instantiation. A flexible IPAM system that respects the authority of each public cloud service while retaining authority in traditional network environments enables versatile automation as well as a holistic view of your entire IP address space. Such an IPAM solution also allows the monitoring of IP address capacity, so you can add and remove subnets as capacity demands dictate.<br />
<br />
Achieve the benefits of the cloud to the fullest extent by automating your IP address and DNS name assignment tasks into your cloud management workflow tasks. Incorporate a robust, scalable and flexible IPAM solution with cloud automation capabilities to fully attain the agility, elasticity and scalability benefits of the cloud.<br />
<div>
<br /></div>
Tim Rooneyhttp://www.blogger.com/profile/01546393894956325009noreply@blogger.com0tag:blogger.com,1999:blog-7912000584263664000.post-8753824505419406572019-03-06T14:19:00.000-05:002019-03-06T14:19:21.388-05:00DNSSEC Root Key Rollover ReduxThe Internet Corporation for Assigned Names and Numbers (ICANN) just published their review of the recent domain name system (DNS) root zone key rollover. The rollover occurred on October 11, 2018. Please read my <a href="https://ipamworldwide.blogspot.com/2018/09/icann-schedules-dnssec-root-key-rollover.html" target="_blank">prior post</a> for background on DNSSEC and role of the root zone key.<br />
<br />
ICANN's summary report concludes that the rollover was indeed an "overwhelming success" given the very small number of disruptions detected during the rollover process. The report provides a logical and thorough timeline of the planning leading up to and encompassing the rollover. The report also highlighted several observations of the rollover process, summarized following:<br />
<br />
<ul>
<li>The vast diversity of resolver software implementations and configurations on the global Internet renders impossible the ability to predict general resolver behavior leading up to and during a rollover. And the lack of measurement capability prevents assured readiness assessment for major DNS changes. So ICANN and the DNS technical community at large was pleasantly surprised with the relatively tiny level of DNS disruptions due to the rollover and subsequent revocation of the prior key in January, 2019. </li>
<li>Given the design principle recommending longer keys (2048 bits in this case) for key signing keys, there was concern that the DNSKEY resource record set would exceed packet transmission sizing and necessitate DNS packet fragmentation. This concern was largely unfounded.</li>
<li>Signalling trust anchor knowledge tactics specified in RFC 8145 proved minimally useful.</li>
<li>Some resolver operators are not well versed on DNSSEC configuration specifics, so operator surveys proved unreliable.</li>
<li>Resolver vendors on the other hand proved knowledgeable and responsive in addressing detected issues.</li>
<li>The lengthy rollover process between announcement of the rollover and its execution reduced the sense of urgency on the process and ICANN communiques related to the process.</li>
<li>While ICANN utilized various forms of outreach to inform the Internet community of the forthcoming rollover, the lack of feedback on each mode makes it difficult to measure effectiveness of each approach.</li>
<li>The ICANN testbed was not helpful in helping users understand and test the impact of the rollover.</li>
</ul>
<div>
The bottom line is that DNSSEC key singing key rollover was incredibly successful, for which all in the ICANN and the Internet community, the DNS community in particular deserve hearty congratulations. Observations from this inaugural rollover will serve to improve the process for the next rollover. Please read the <a href="https://www.icann.org/en/system/files/files/review-2018-dnssec-ksk-rollover-04mar19-en.pdf" target="_blank">full report</a> for full details.</div>
<br />
<br />
<br />Tim Rooneyhttp://www.blogger.com/profile/01546393894956325009noreply@blogger.com0tag:blogger.com,1999:blog-7912000584263664000.post-71404600093585438432019-01-22T14:23:00.000-05:002019-01-22T14:23:26.653-05:00Are you ready for DNS Flag Day?They were only trying to do the right thing. When a recursive DNS server issues a query using DNS Extensions (EDNS) to another DNS server and the answer indicates a format error or there is no answer at all, developers of various recursive DNS server implementations created workarounds such as reissuing the query without extensions or querying another server authoritative for the same zone. This philosophy centered on coding the recursive server to fetch an answer even if it meant trying to ask in many different forms.<br />
<br />
While a noble pursuit in "doing what it takes" to obtain an answer, these and similar workarounds introduce additional queries of various formats and additional processing requirements on the recursive server. These inefficiencies, while intended to satisfy the requirement of answering the query, are needlessly reducing performance and scalability of the Internet. And as more extension features are introduced, complexity of recursive server software will increase; and if such code must include workarounds for each new feature, the inefficiencies and fragility of the code become untenable.<br />
<br />
EDNS was initially defined in 1999 as RFC 2671 as a means to expand existing constraints of defined DNS protocol message field sizes and to enable advertising of supported extension capabilities to queried DNS servers. The intent was to enable extension of the DNS protocol to support more response codes, enable larger message payloads, e.g., for DNSSEC, and to facilitate support for new features.<br />
<br />
Since its inception, EDNS now enables such feature extensions as providing the responding name server identity (NSID, useful particularly in anycast deployments), DNS-over-TCP keepalive messages, signalling of DNSSEC algorithm support, client subnet (used by authoritative servers to provide query answers "close" to the querier), and DNS cookies (a lightweight DNS transaction security mechanism).<br />
<br />
RFC 2671 has been updated and obsoleted by RFC 6891 which mandated all DNS servers support the OPT resource record type, the prime mechanism of EDNS. Now major DNS vendors are mandating fully compliant support of EDNS. February 1, 2019 is DNS Flag Day, or perhaps more appropriately EDNS Flag Day. As of this date, major open source DNS software will begin to make available software updates to remove the EDNS workarounds and apply strict conformance to EDNS standards. How will this affect you?<br />
<br />
First, don't panic. If your recursive DNS servers do not fully comply with the new less tolerant EDNS processing recommendations, your servers should continue to support fully compliant and perhaps those not fully compliant, but you will be contributing to a less efficient Internet. In addition, your recursive servers may not support some or all of the aforementioned DNS feature extensions.<br />
<br />
If your authoritative DNS servers do not fully and compliantly support EDNS, strictly compliant recursive servers querying your namespace to reach your web server, email server, etc., may have queries go unanswered. If your server does not answer using EDNS as requested and in the proper format, the querier not reattempt the query. You can check your level of compliance by entering your domain name at <a href="https://dnsflagday.net/">https://dnsflagday.net</a>. If you are not compliant, remember the flag day stipulates the beginning of software availability of strict EDNS processing. Talk with your DNS vendor and plan to upgrade as soon as practical to make full avail of your namespace.Tim Rooneyhttp://www.blogger.com/profile/01546393894956325009noreply@blogger.com0tag:blogger.com,1999:blog-7912000584263664000.post-71409231129086870482018-11-13T11:30:00.000-05:002018-11-13T11:30:55.759-05:00Your domain by any other nameYour domain name represents your identity on the Internet. Customers, prospects, associates, and generally anyone on the Internet can navigate to your website simply by knowing your domain name. The domain name system (DNS) facilitates this naming process by enabling the resolution of your site's name to Internet Protocol addresses that devices use to connect to your website over the Internet.<br />
<br />
While DNS simplifies navigation to your Internet presence thanks to your domain name, it also introduces an exposure to visual misrepresentations of your domain name in the DNS and therefore on the Internet. Such misrepresentations may be totally innocent, such as when would-be visitors "fat finger" or mistype your web address in their browsers leading them to another website, or downright malicious where a miscreant creates a website reachable by a visually similar or slight variation in your domain name.<br />
<br />
Such a malicious website could be designed to visually appear similar to yours and serve as a means to solicit personal information, to entice the download of malware, to smear your brand, or to monetize web visits via advertisements or affiliated links. Other motivations for malicious registration of similar domain names include misrepresenting your brand, siphoning web traffic to a competitor, or merely holding the domain name for sale to the "rightful" domain holder.<br />
<br />
The registration of a similar domain for such purposes is broadly referred to as cybersquatting and may take one of many forms:<br />
<br />
<ul>
<li>Brandjacking - the registration of a domain name for a company or celebrity. This "exact match" approach may embolden the domain holder to sell at an exorbitant price or otherwise abuse the domain's integrity as previously discussed.</li>
<li>Typosquatting - various forms of a domain name representation including a close misspelling or use of a different top level domain, such as "org" instead of "com" or a country code top level domain such as "co" instead of "com."</li>
<li>Homoglyphs - use of similar characters within a domain name such as the number one in place of the letter l. By Internet standards, domain names must be encoded in the DNS as ASCII characters. Internationalized domain names (IDNs) are a special form of domain name, which represent non-Latin domain names as ASCII. That is, your browser can display links or enable entry of domain names in native language. e.g., Cyrillic, and DNS will resolve the corresponding ASCII representation or IDN. Some non-Latin characters appear to the eye as Latin characters, and users may easily misconstrue character sets, thereby arriving at a website other than that intended. </li>
</ul>
<div>
What can you do if you find a domain name similar to yours that appears to be maligned? The <a href="https://www.icann.org/resources/pages/policy-2012-02-25-en" rel="nofollow" target="_blank">Uniform Domain Name Dispute Resolution Policy</a> (UDRP) was been established by the Internet Corporation for Assigned Names and Numbers (ICANN) in conjunction with the United Nations' World Intellectual Property Organization (WIPO) in 1999. The policy requires the complainant to establish that the domain is identical or confusingly similar to their trademark or service mark, that the registrant has no legitimate interests in the domain name and the that domain name is being used in bad faith.</div>
<div>
<br /></div>
<div>
For additional discussion about domain name abuses, please check out <a href="https://www.youtube.com/watch?v=-_bT15rlZ3Q" target="_blank">my video</a>.</div>
<div>
<br /></div>
Tim Rooneyhttp://www.blogger.com/profile/01546393894956325009noreply@blogger.com0tag:blogger.com,1999:blog-7912000584263664000.post-87757845045839458272018-11-01T09:19:00.000-04:002018-11-01T09:19:23.996-04:00DNS security battlecardNeed a quick summary of essential DNS security measures on a single page? I've published a <a href="http://www.ipamworldwide.com/btdiamondip/dns-security-battlecard.pdf" rel="nofollow" target="_blank">DNS Security Battlecard</a> just for you. My intention is to "net out" the key measures you should consider to better secure your DNS and thereby better secure your overall network. The battlecard summarizes, for each DNS server role, various controls you can implement related to deployment, routing controls, server controls and DNS application/protocol controls.<br />
<br />
Beyond the network and server level controls highlighted in the battlecard, please do not forget the human element of security that pervades all DNS server roles. This includes developing and enforcing an organizational security policy, incorporating security functions and requirements into staff job descriptions, staffing of personnel with appropriate job-specific skill sets, regular training of security policies and controls, and periodic auditing of staff activities.<br />
<br />
Other enterprise-wide security considerations include documenting business continuity/disaster recovery plans, implementing supply-chain controls, protecting data, and communicating detected threats and resolutions with the cybersecurity community. These broader controls are defined in the National Institute of Standards and Technologies (NIST) Cybersecurity Framework (CSF). The CSF is a de facto security implementation standard not only for the U.S. government, but for organizations worldwide. I invite you read my <a href="https://ipamworldwide.blogspot.com/2018/10/nist-cybersecurity-framework-core.html" target="_blank">prior post</a> for my perspective on applying the CSF to DNS.<br />
<br />
While the CSF as applied to DNS provides a broader perspective on suggested security outcomes, the <a href="http://www.ipamworldwide.com/btdiamondip/dns-security-battlecard.pdf" rel="nofollow" target="_blank">DNS Security Battlecard</a> offers a focused albeit brief summary of requisite network, server and DNS controls you can implement for improved network security.<br />
<br />
<br />
<br />Tim Rooneyhttp://www.blogger.com/profile/01546393894956325009noreply@blogger.com0tag:blogger.com,1999:blog-7912000584263664000.post-63294369376120058472018-10-17T08:47:00.000-04:002018-11-06T13:07:22.064-05:00Common DNS attacksThe Domain Name System (DNS) makes the Internet usable for humans. It is fundamental to the proper operation of virtually all Internet Protocol (IP) network applications, from web browsing to email, from messaging to multi-media applications and more. By its very nature, the global Internet DNS system serves as a distributed data repository containing domain names (e.g., web addresses) and corresponding IP address information. DNS has proven extremely effective and scalable in practice and most people take DNS for granted given its proven reliability. However, its essential function and decentralized architecture serve to attract attackers seeking to exploit its distributed structure and rich data store for sinister activities.<br />
<br />
Every time you enter a web address or send an email, you use DNS. DNS translates human-preferred "www" names into computer-preferred binary addresses. This translation service is more commonly referred to as a name resolution process, whereby a web address is <i>resolved </i>to its IP address. And a given web page may stimulate several DNS lookups, with encoded hypertext reference (href), source (src) and other tags that contain a unique domain name. Each of these stimulate your browser to perform a DNS lookup to fetch the referenced image, video, file or script, and perhaps pre-fetch links. And each time you click a link to navigate to a new page, the process repeats with successive DNS lookups required to fully render the destination page.<br />
<br />
Email relies on DNS for email delivery, enabling you to send email using the familiar user@destination syntax, where DNS identifies the destination’s IP address for transmission of the email. And DNS goes well beyond web or email address resolution. Virtually every application on your computer, tablet, smartphone, security cameras, thermostats and other “things” that access the Internet require DNS for proper operation. Without DNS, navigating and accessing Internet applications would be all but impossible.<br />
<br />
This leads to our first motivator for attacking DNS: to wreak havoc! An outage or an attack that renders your DNS service unavailable or which manipulates the integrity of the data contained within DNS can effectively bring a network down from an end user perspective. Even if network connectivity exists, you won't be able to connect unless of course you already know the IP address of the site to which you’d like to connect, which would certainly evince you as uniquely talented. But even under such circumstance while you’d be unable to connect, you wouldn’t see any linked images or content which rely on DNS for locating and rendering.<br />
<br />
Attacks that can bring down your DNS services include server attacks, attacks leveraging known vulnerabilities, and denial of service attacks. Domain hijacking is another form of attack whereby an attacker manipulates the domain structure to impersonate your domain. Man-in-the-middle attacks, where an attacker can trick a resolver to accepting a falsified query answer can lead resolvers unwittingly to impostor websites.<br />
<br />
The second and potentially more menacing motivator is the use of DNS as an attack vehicle, particularly as covert transport. Just as DNS is the first step in allowing users to connect to websites, it is likewise usable by bad actors to connect to internal targets within your enterprise and external command and control (C&C) centers for updates and directives to perform nefarious tasks. Given the foundational necessity of DNS, DNS traffic is generally permitted to flow freely through networks, exposing networks to attacks that leverage this freedom of communications for name resolution or for tunneling of data out of the organization.<br />
<br />
An attacker may attempt to install malware on one or more of your users' devices to enroll it under the control of the attacker individually or as an unwitting member of a botnet. A botnet is a collection of devices infected with the attacker's malware which can be summoned to perform nefarious tasks at the behest of the attacker. Such malware may be installed via several avenues, including phishing or spear phishing attacks that bait users into opening executable email attachments or installing software from an attacker website. Whether a device is attacked while inside the enterprise network or a user device is infected then physically brought onto the network, if the device is trusted within the confines of an enterprise network it may have access to sensitive information. The malware may perform data collection, locating internal data sources using DNS for reconnaissance for internal targets. Then DNS can be used to identify the current IP address of the attacker’s external destination for exfiltration of sensitive information.<br />
<br />
A reflection or amplification attack is another attack form which utilizes DNS as an attack instrument. DNS queries are sent to DNS servers using a spoofed source IP address. This spoofed address, the attack target, will receive the responses for these queries, which in large volumes can deny service at the target.<br />
<br />
While DNS is the first step in IP communications, many enterprise security strategies trivialize or startlingly even ignore its role in communications and therefore its susceptibility to attacks on this vital network service or on the network itself. Most security strategies and solutions focus on filtering “in-band” communications flow in order to detect and mitigate cyber-attacks. But DNS traffic provides an additional stream of information that can be used to help identify and troubleshoot attack incidents.<br />
<br />
Consider adding a DNS layer to your defense in depth security approach. This DNS layer is comprised of several approaches that help identify and mitigate DNS attacks as summarized below. I've linked some topics to videos that provide more details regarding respective topics while other will be addressed in future posts.<br />
<br />
<table cell-padding="1" style="margin-left: 16px;"><tbody>
<tr><th>Attack type</th><th></th><th>DNS Defense Mechanism</th>
</tr>
<tr><td><a href="https://www.youtube.com/watch?v=KURJDbc5KKA" target="_blank">DNS server attack</a></td><td></td><td>Role deployment, ACLs, server hardening</td></tr>
<tr><td>DNS, OS vulnerabilities</td><td></td><td>Apply patches, upgrades</td></tr>
<tr><td><a href="https://www.youtube.com/watch?v=MsRQ3gBvXz0" target="_blank">DNS denial of service</a></td><td></td><td>Anycast and DNS rate limiting</td></tr>
<tr><td><a href="https://www.youtube.com/watch?v=42XxgQ7zxKY" target="_blank">DNS domain hijacking</a></td><td> </td><td>Parent zone integrity checking</td></tr>
<tr><td><a href="https://www.youtube.com/watch?v=dmK0seFlb3E" target="_blank">Man in the middle data manipulation</a></td><td></td><td>DNSSEC</td></tr>
<tr><td><a href="https://www.youtube.com/watch?v=nii64MuDvu0&list=PLt7dJbVNtnznzrme7nqAxUZGY5Md6pfK3&index=4" target="_blank">Malware querying its C&C Center</a></td><td></td><td>DNS Firewall</td></tr>
<tr><td><a href="https://www.youtube.com/watch?v=jL2CHOFqNgs" target="_blank">DNS tunneling</a></td><td></td><td>DNS traffic and entropy analysis</td></tr>
<tr><td><a href="https://www.youtube.com/watch?v=q4qA2pNJ6hg" target="_blank">DNS reflection attack</a></td><td></td><td>DNS response rate limiting</td></tr>
<tr><td>Unencrypted DNS information in transit</td><td> </td><td>DNS over TLS, DNS over HTTPS, DNScrypt</td></tr>
</tbody></table>
Tim Rooneyhttp://www.blogger.com/profile/01546393894956325009noreply@blogger.com0tag:blogger.com,1999:blog-7912000584263664000.post-55695298847985025792018-10-08T13:36:00.000-04:002018-10-08T13:36:07.248-04:00Proper DNS deployment one key to DNS securityTwo basic tenants of information technology (IT) network security practices entail partitioning DNS server deployments and corresponding functions based on trust zones and in employing a multi-layered defense in depth style approach. I’ll use the term “trust sectors” instead of “trust zones” given the ambiguity of the word “zone” in a DNS context. Establishing an effective defense is critical as is preparation, monitoring, event detection to rapidly identify attacks in progress and enact recovery plans to perform mitigation actions to minimize or nullify their impacts. Event post-mortems are also critical to feeding back to the security plan to apply lessons learned to improve detection and recovery times.<br />
<br />
Generally, DNS deployment designs should account for high availability, performance, scalability, human intervention and of course, security. Using a trust sector approach to DNS server deployment allows you to segment namespace and resolution responsibility which provides a solid foundation for achieving these objectives. Keep in mind that there is no “one size fits all” cookie cutter deployment architecture. However, by defining role-based server configurations as trust sectors, you can select which are applicable based on your environment’s scale and policies.<br />
<br />
Based on the flow of DNS queries, I recommend defining the following four trust sectors based on query source and the context of the query.<br />
<br />
<ol>
<li>Recursive trust sector - this sector comprises internal (within the organization) queriers (stub resolvers) querying recursive servers out through a demilitarized zone (DMZ) to the Internet. This trust sector enables internal clients to access external/Internet websites and by necessity requires access to and from the Internet with associated security controls.</li>
<li>Internal trust sector - internal stub resolvers desiring to access intranet sites make use of the internal trust sector. This sector comprises stub resolvers querying recursive servers which forward to internal authoritative DNS servers. As internal and presumably more sensitive destinations are published through these internal authoritative servers, security measures are required to control access to such information which could provide attackers a set of potential targets.</li>
<li>External trust sector - this sector comprises your external or Internet-facing DNS infrastructure, whether in-house, outsourced or both. These servers publish Internet reachable destinations such as web and email servers. Query access is generally open to all, but important steps are required to disable recursion, mitigate reflector attacks, and prevent breaching your internal DNS or network in general.</li>
<li>Extranet trust sector - for partners or suppliers, some organizations publish server information to support access to information such as inventories or pricing. Controls are required to constrain access only to said partners and to prevent infiltration into the internal network. </li>
</ol>
<br />
I invite you to check out my <a href="https://youtu.be/KURJDbc5KKA" target="_blank">DNS trust sector video</a> for more information and details about configuring DNS servers and affiliated network elements to achieve a DNS security zones deployment in your network.Tim Rooneyhttp://www.blogger.com/profile/01546393894956325009noreply@blogger.com0tag:blogger.com,1999:blog-7912000584263664000.post-88569672119745264562018-10-01T13:22:00.000-04:002018-10-01T13:22:51.067-04:00NIST Cybersecurity Framework Core applied to DNSThe National Institute of Standards and Technologies (NIST) Cybersecurity Framework (CSF) is a de facto security implementation standard not only for the U.S. government, but for organizations worldwide. This framework defines a common lexicon to facilitate documentation and communication of security requirements and level of implementation. In addition, the framework enables an organization to identify risks and to prioritize the mitigation of risks with respect to business priorities and available resources.<br />
<br />
NIST’s CSF seeks to facilitate communications within an organization as well as to external parties when conveying security goals, maturity status, improvement plans and risks. The framework is comprised of three major components:<br />
<br />
<ul>
<li>The framework core defines security activities and desired outcomes for the lifecycle of an organization’s management of cybersecurity risk. The core includes detailed references to existing standards to enable common cross-standard categorization of activities. The core defines these activities across five functions: </li>
<ul>
<li>Identify – deals with what systems, assets, data and capabilities require protection</li>
<li>Protect – implement safeguards to limit the impact of a security event</li>
<li>Detect – identification of incidents</li>
<li>Respond – deals with security event management, containing incident impacts</li>
<li>Recover – resilience and restoration capabilities</li>
</ul>
</ul>
<ul>
<li>The framework profile defines the mechanism for assessing and communicating the current level of security implementation as well as the desired or planned level of implementation. The profile applies business constraints and priorities, as well as risk tolerance to the framework core functions to characterize a particular implementation scenario. </li>
</ul>
<ul>
<li>The framework implementation tiers define four gradations of maturity level of security implementations, ranging from informal and reactive to proactive, agile and communicative:</li>
<ul>
<li>Tier 1 – Partial – Informal, ad hoc, reactive risk management practices with limited organizational level risk awareness and little to no external participation with other entities.</li>
<li>Tier 2 – Risk Informed – Management-approved with widely established organization-wide risk awareness but with informal and limited organization-wide risk management practices and informal external participation.</li>
<li>Tier 3 – Repeatable – Risk management practices are formally approved as policy with defined processes and procedures which are regularly updated based on changes in business requirements as well as the threat and technology landscape. Personnel are trained and the organization collaborates with external partners in response to events.</li>
<li>Tier 4 – Adaptive – Organization-wide approach to managing cybersecurity risk where practices are adapted to the changing cybersecurity landscape in a timely manner. The organization manages risk and shares information with partners.</li>
</ul>
</ul>
The implementation tiers enable an organization to apply the rigor of their selected maturity level to their target profile definition to align risk management practices to the particular organization’s security practices, threat environment, regulatory requirements, business objectives and organizational constraints.<br />
<br />
We defined a mapping of the NIST CSF version 1.0 to DNS-specific outcomes in our <i>DNS Security Management </i>book, which I co-authored with Michael Dooley, as published by Wiley IEEE Press in 2017. I've updated this mapping to apply to the latest <a href="http://www.ipamworldwide.com/btdiamondip/nist-csf-dns.pdf" rel="nofollow" target="_blank">version 1.1</a> of the CSF. This mapping is intended as input to your application and interpretation of the CSF for DNS and any feedback is welcomed. I hope this helps you assess your current standing and to prioritize actions towards securing your DNS with this de facto security standard as a guide.Tim Rooneyhttp://www.blogger.com/profile/01546393894956325009noreply@blogger.com0