Jump to content

DNS Abuse Responses: Difference between revisions

From ICANNWiki
Jessica (talk | contribs)
Jessica (talk | contribs)
No edit summary
Line 67: Line 67:
|  || 6. The study also recommends setting up a standardized (and potentially centralized) system for abuse reporting, identifying the minimum information necessary to process such reports. The receipt of abuse reports is to be acknowledged. The reaction time to such reports shall be clearly defined and the abuse reporter should be provided with information on the actions taken. The DNS service providers shall provide for an appeal proceeding against their decisions to a third neutral party || 11. registries and registrars should use predictive algorithms to prevent abusive registrations ||  || 20. Internet Service Providers operating DNS resolvers should configure DNSSEC validation to protect end users from cache poisoning attacks || 27. all intermediaries and stakeholders should share knowledge and do capacity building in the fight against DNS abuse
|  || 6. The study also recommends setting up a standardized (and potentially centralized) system for abuse reporting, identifying the minimum information necessary to process such reports. The receipt of abuse reports is to be acknowledged. The reaction time to such reports shall be clearly defined and the abuse reporter should be provided with information on the actions taken. The DNS service providers shall provide for an appeal proceeding against their decisions to a third neutral party || 11. registries and registrars should use predictive algorithms to prevent abusive registrations ||  || 20. Internet Service Providers operating DNS resolvers should configure DNSSEC validation to protect end users from cache poisoning attacks || 27. all intermediaries and stakeholders should share knowledge and do capacity building in the fight against DNS abuse
|-
|-
|  || 7. We encourage the exchange of information on threats between parties involved (e.g., CERTs, security organizations) using collaborative platforms such as Malware Information Sharing Platform (MISP) to report and mitigate abuse in a more effective and timely way. || 12. Registries' and registrars' abuse rates should always be monitored by independent researchers with institutions and regulatory bodies; their abuse rates should not exceed predetermined thresholds; if they exceed the thresholds and do not improve, [[accreditation]] could be revoked ||  || 21. National CERT teams should subscribe to data sources that identify open DNS resolvers; should intensify notification efforts to reduce the number of open DNS resolvers, the root cause of distributed reflective (DR)[[DoS Attack]]s ||  
|  || 7. We encourage the exchange of information on threats between parties involved (e.g., CERTs, security organizations) using collaborative platforms such as Malware Information Sharing Platform (MISP) to report and mitigate abuse in a more effective and timely way. || 12. Registries' and registrars' abuse rates should always be monitored by independent researchers with institutions and regulatory bodies; their abuse rates should not exceed predetermined thresholds; if they exceed the thresholds and do not improve, [[Registrar Accreditation Agreement|accreditation]] could be revoked ||  || 21. National CERT teams should subscribe to data sources that identify open DNS resolvers; should intensify notification efforts to reduce the number of open DNS resolvers, the root cause of distributed reflective (DR)[[DoS Attack]]s ||  
|-
|-
|  ||  || 13. registries and registrars with lower abuse rates could be financially rewarded, through a reduction in domain registration fees ||  || 22. The [[Cybersecurity]] community should continuously measure the adoption of SPF and DMARC protocols, especially for high-risk domain names; raise awareness of domain spoofing among domain owners and email service providers; and correct and toughen SPF and DMARC rules to mitigate email spoofing/Business Email Compromise scams ||  
|  ||  || 13. registries and registrars with lower abuse rates could be financially rewarded, through a reduction in domain registration fees ||  || 22. The [[Cybersecurity]] community should continuously measure the adoption of SPF and DMARC protocols, especially for high-risk domain names; raise awareness of domain spoofing among domain owners and email service providers; and correct and toughen SPF and DMARC rules to mitigate email spoofing/Business Email Compromise scams ||  

Revision as of 17:12, 8 March 2022

DNS Abuse Responses are the various tools, methods, collaboration, and philosophies spawning from DNS Abuse itself.

Overview[edit | edit source]

There are four time-related categories of responses to DNS Abuse:

  1. reactionary detection and removal of sources of abuse (necessarily after the fact),
  2. cotemporal efforts to mitigate the amount and likelihood of abuse or its impact,
  3. future-focused work on stopping abuse before it can happen, and
  4. ongoing allowance of abuse for ideological or jurisdictional reasons.

Response Options[edit | edit source]

Reactionary Removal[edit | edit source]

Cotemporal Mitigation[edit | edit source]

Prevention[edit | edit source]

Intentional Inaction & Evidentiary Collection[edit | edit source]

Points of View[edit | edit source]

Every type of Internet user has worries over DNS Abuse and the responses to it. For instance, there is an ongoing multistakeholder debate over where to draw the line between technical abuse and content abuse. Moreover, there are technical limits on what each type of stakeholder can do to stop abuse.

Social Scientists[edit | edit source]

Criminologists feel the capacity to regulate DNS abuse is very limited because:

  1. no single global entity is responsible for the regulation of all its aspects;
  2. the Multistakeholder Model of governance and the distributed administration model allows disagreements and discrepancies;
  3. much of what happens on the Internet is beyond the jurisdictional reach of the criminal law of individual nations; and
  4. regulation will continue to be reserved for the most egregious infringements.

Regulation will remain limited until a uniform set of policies to prevent abuse before it happens is enacted.[1]

Intergovernmental Organizations[edit | edit source]

IGO responses generally treat DNS Abuse as a facet of Cybercrime.

Objectives[edit | edit source]

Pro-Mitigation[edit | edit source]
EC DNS Abuse Study Recommendations[edit | edit source]

The EC conducted a study on DNS abuse, which generated the following recommendations for all actors in the DNS ecosystem.[2]

A. Better DNS Metadata for identifying resources and their attribution to intermediaries B. Contact Information and Abuse Reporting C. Improved Prevention, Detection, and Mitigation of DNS Abuse via maliciously registered domain names D. Improved Detection and Mitigation of (compromised) domain names distributing malicious content E. Better Protection of the DNS Operation and Preventing Abuse of the DNS F. DNS Abuse Awareness, Knowledge Building, and Mitigation Collaboration
1. ccTLDs registries should provide a scalable, unified way of accessing complete registration data in compliance with data protection laws, using RDAP 3. Registrants' and domain name administrators' email addresses that are not visible in the public WHOIS should be displayed as anonymized email addresses 8. TLD registries, registrars, and resellers should verify domain registration data accuracy; implement harmonized Know Your Business Customer procedures or eID authentication in accordance with the eIDAS Regulation, using cross-checks in other publicly available and reputed databases 15. the abuse rates of hosting providers should always be monitored by independent researchers with institutions and regulatory bodies; abuse rates should not exceed predetermined thresholds; incentive structures should be studied to induce hosting providers 17. ccTLDs should be required to sign TLD zone files with DNSSEC and facilitate its deployment according to good practices 24. EU ccTLDs should harmonize practices and adopt good practices
2. ccTLDs registries should publish DNS zone file data through DNS zone transfer or a system similar to the Centralized Zone Data Service 4. domain name administrators should maintain RFC 2142 specific email aliases for domain names (e.g., abuse, hostmaster, webmaster) and an email in the DNS SOA record 9. registries should develop/improve search tools or surveillance services to enable third parties to identify names that could potentially infringe their rights 16. operators of free services should employ advanced prevention and remediation solutions to curb abuses of subdomain names and hosting infrastructure; should proactively detect suspicious domain names containing keywords of the most frequently targeted brands and names; and work with heavily attacked companies and develop Trusted Notifier programs 18. registrants should have easy access to DNSSEC signing within the TLD; registries should require their registrars to support DNSSEC signing for registrants 25. DNS service providers should collaborate with EU and Member States’ institutions, law enforcement authorities, and Trusted Notifiers or trusted flaggers; formalize informal collaborations
5. A standardized (and potentially centralized) system for access to registration data (WHOIS data) should be set up, identifying the minimum information necessary to process disclosure requests. The reaction time to such requests shall be clearly defined 10. registries should offer, directly or through the registrars/resellers, services allowing intellectual property rights holders to block infringing domain name registrations 19. registries could offer discounts for DNSSEC-signed domain names 26. consumers and IPR holders should be made aware of measures to tackle DNS abuse.
6. The study also recommends setting up a standardized (and potentially centralized) system for abuse reporting, identifying the minimum information necessary to process such reports. The receipt of abuse reports is to be acknowledged. The reaction time to such reports shall be clearly defined and the abuse reporter should be provided with information on the actions taken. The DNS service providers shall provide for an appeal proceeding against their decisions to a third neutral party 11. registries and registrars should use predictive algorithms to prevent abusive registrations 20. Internet Service Providers operating DNS resolvers should configure DNSSEC validation to protect end users from cache poisoning attacks 27. all intermediaries and stakeholders should share knowledge and do capacity building in the fight against DNS abuse
7. We encourage the exchange of information on threats between parties involved (e.g., CERTs, security organizations) using collaborative platforms such as Malware Information Sharing Platform (MISP) to report and mitigate abuse in a more effective and timely way. 12. Registries' and registrars' abuse rates should always be monitored by independent researchers with institutions and regulatory bodies; their abuse rates should not exceed predetermined thresholds; if they exceed the thresholds and do not improve, accreditation could be revoked 21. National CERT teams should subscribe to data sources that identify open DNS resolvers; should intensify notification efforts to reduce the number of open DNS resolvers, the root cause of distributed reflective (DR)DoS Attacks
13. registries and registrars with lower abuse rates could be financially rewarded, through a reduction in domain registration fees 22. The Cybersecurity community should continuously measure the adoption of SPF and DMARC protocols, especially for high-risk domain names; raise awareness of domain spoofing among domain owners and email service providers; and correct and toughen SPF and DMARC rules to mitigate email spoofing/Business Email Compromise scams
14. registries should maintain access to RBLs, identify their registrars with the highest and lowest concentrations and rates of DNS abuse, propose incentive structures to encourage their registrars to prevent and mitigate malicious registrations 23. Network operators should deploy IP Source Address Validation for all traffic at the edge of a network to protect closed DNS resolvers from different external attacks against DNS infrastructure, including possible zero-day vulnerabilities within the DNS server software
Pro-privacy[edit | edit source]
  • Pro-privacy legislation, such as the GDPR and the CCPA, limits access to natural persons' data.

Government Responses[edit | edit source]

Government responses tend to focus on what can be adjudicated; include content abuse, such as child pornography; and outline how and when electronic evidence can be collected.

Domestic Legislation[edit | edit source]
U.S. Federal[edit | edit source]

American cybersecurity legislation thus far has focused on standardizing and formalizing preventative measures.[3] Congress passed

State[edit | edit source]
CISA[edit | edit source]

The CISA seeks to prevent future cyberattacks on critical infrastructure. Its CDM Program is a dynamic approach to fortifying the cybersecurity of civilian government networks and systems. Its Stop Ransomware Website is a one-stop shop for preparing for ransomware attacks among other forms of malware.

FBI[edit | edit source]

The FBI leads the National Cyber Investigative Joint Task Force (NCIJTF) and runs the public-facing Internet Crime Complaint Center (IC3) to collect cybercrime and electronic evidence of other types of crimes.

DOD[edit | edit source]
NIST[edit | edit source]
NCCoE
NICE
Responding to State-Sponsored Cyberattacks[edit | edit source]
Sanctions/Condemnations[edit | edit source]
  • SolarWinds Hacking Attack: In an executive order issued April 15, 2021, President Biden levied economic sanctions against Russian financial institutions, technology companies, and individuals that participated in this series of hacks that infiltrated nine federal agencies and over 100 private companies.[6]
  • Microsoft Email Systems Hacking Attack: On July 19, 2021, the Biden administration formally condemned but did not inflict sanctions against the Chinese government for working with hackers to breaching Microsoft email systems.[7]

Technical Community[edit | edit source]

Internet Governance Organizations[edit | edit source]

ICANN[edit | edit source]

ICANN has been steadfast in its focus on technical DNS abuse, what it calls "DNS security threats," and avoidance of policymaking around content abuse. ICANN has two missions related to DNS Abuse: maintaining the SSR of the DNS and engendering trust in the domain name industry. ICANN's determination of the org's definition for DNS Abuse is based on the work product of GAC and the base gTLD Registry Agreement. Thus, ICANN considers DNS security threats to be limited to attacks involving phishing, malware, botnet command and control, pharming, and spam as a vector.[8] As recently as ICANN 71, the ICANN board was criticized by members of the ALAC, the BC, and other Internet Governance bodies for not doing enough to steward contracted parties and non-contracted parties toward involvement in reducing abuse. However, ICANN and SSAC, in particular, have begun pointing to SAC115 and DAAR as evidence of their work on addressing DNS abuse. Parts of ICANN Organization, Board, and Community that are dedicated to resolving DNS Abuse issues:

IGF[edit | edit source]

DNS Abuse Institute[edit | edit source]

Currently, this newcomer is entirely focused on creating an interoperable framework to reduce DNS abuse. The DNSAI acknowledges there are two options for reducing security threats: proactive and reactive methods. The institute is currently putting more of its energy into developing reactive tools because they can be used by anti-abuse or compliance personnel without requiring integration in registration platforms and thus, broad buy-in should be easier to secure.[13]

Private Sector[edit | edit source]

Cybersecurity Providers[edit | edit source]

The cybersecurity industry is booming and is trying various approaches to protect networks and supply chains from data breaches and ransomware attacks. For instance, Prevailion's strategy is to hack the hackers, while McAfee remains the revenue leader by continuing to churn out cybersecurity software.[14]

Registries and Registars[edit | edit source]

European ccTLD Registries[edit | edit source]

Sebastian Felix Schwemer's 2020 analysis of 30 European ccTLD terms of services (ToS) showed several responses to use/content-related domain name abuse, including no related reservations, reactions to severe cases, and proactive screening.[15] Some ToSes do not contractually reserve to take down a domain name due to use or content, while others do reserve the right to take down a domain name but only in severe situations. Others have established "takedown regimes" akin to that of site operators, hosting providers, and registrants (per Article 14 of the E-Commerce Directive. EURid, .be, and SIDN have begun to screen abusive use by crawling content, using fuzzy hashes, or HTML structural similarity analysis; they are also working on early warning systems. Schwemer found that only 1/3 of ccTLD ToSes contained content/use provisions and that the discretion for registrars to take down domain names via a morality clause was higher than it was for ccTLD registries. This analysis also revealed the emergence of ccTLD registries' use of data validation in a new way. Registries have noticed a correlation between domain names engaging in unlawful activities and the provision of poor registration data. Because ToSes can reserve the right to terminate registrations based on wrong or inaccurate information, some ccTLD registries are using this term as a workaround.[16]

DNS Abuse Framework[edit | edit source]

This framework was developed by registries and registrars. The framework discourages a registry or registrar from taking action against domains, except in certain types of Website Content Abuse:

  1. child sexual abuse materials,
  2. illegal distribution of opioids online,
  3. human trafficking, or
  4. specific, credible incitements to violence
  1. include their own acceptable use policies or terms of use to set forth provisions to cover Website Content Abuses,
  2. contract Trusted Notifiers to monitor content and report abuse
  1. Have to determine whether the domain in question was maliciously registered or if the domain has been compromised. Registries cannot generally directly remediate a compromised domain; instead, it is up to the sponsoring registrar.[17] Conversely, if a domain has been maliciously registered, the registry has six options:
  2. Suspend the domain (most common)
  3. Refer to the sponsoring registrar
  4. Lock the domain
  5. Redirect a domain by changing the name servers
  6. Transfer the domain
  7. Delete the domain (generally considered an ineffective and extreme response)
If a registry encounters unregistered domain names resulting from an automatic Domain Generation Algorithm (DGA), the operator can:
  1. Reserve the domains or
  2. create the domains in order to suspend or sinkhole the domains for victim identification

Reputation Industry[edit | edit source]

Commercial service providers, researchers, and non-profit organizations operate the most prominent RBLs that detect or receive notifications of security threats. Some key players include:

End Users[edit | edit source]

End users, even those who work in the DNS industry, need help managing DNS Abuse mainly because of the timeless effectiveness of Social Engineering Attacks. For instance, at the end of 2020, GoDaddy notoriously tested its workers to see if they would share sensitive information after clicking on dubious links from a spoofed email.[18]

References[edit | edit source]