Hubbry Logo
Blacklist (computing)Blacklist (computing)Main
Open search
Blacklist (computing)
Community hub
Blacklist (computing)
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Blacklist (computing)
Blacklist (computing)
Blacklist (computing)
View on Wikipedia
from Wikipedia
Screenshot of a website blocking the creation of content which matches a regular expression term on its blacklist

In computing, a blacklist, disallowlist, blocklist, or denylist is a basic access control mechanism that allows through all elements (email addresses, users, passwords, URLs, IP addresses, domain names, file hashes, etc.), except those explicitly mentioned. Those items on the list are denied access. The opposite is a whitelist, allowlist, or passlist, in which only items on the list are let through whatever gate is being used. A greylist contains items that are temporarily blocked (or temporarily allowed) until an additional step is performed.

Blacklists can be applied at various points in a security architecture, such as a host, web proxy, DNS servers, email server, firewall, directory servers or application authentication gateways. The type of element blocked is influenced by the access control location.[1] DNS servers may be well-suited to block domain names, for example, but not URLs. A firewall is well-suited for blocking IP addresses, but less so for blocking malicious files or passwords.

Example uses include a company that might prevent a list of software from running on its network, a school that might prevent access to a list of websites from its computers, or a business that wants to ensure their computer users are not choosing easily guessed, poor passwords.

Examples of systems protected

[edit]

Blacklists are used to protect a variety of systems in computing. The content of the blacklist is likely needs to be targeted to the type of system defended.[2]

Information systems

[edit]

An information system includes end-point hosts like user machines and servers. A blacklist in this location may include certain types of software that are not allowed to run in the company environment. For example, a company might blacklist peer to peer file sharing on its systems. In addition to software, people, devices and Web sites can also be blacklisted.[3]

Email

[edit]

Most email providers have an anti-spam feature that essentially blacklists certain email addresses if they are deemed unwanted. For example, a user who wearies of unstoppable emails from a particular address may blacklist that address, and the email client will automatically route all messages from that address to a junk-mail folder or delete them without notifying the user.

An e-mail spam filter may keep a blacklist of email addresses, any mail from which would be prevented from reaching its intended destination. It may also use sending domain names or sending IP addresses to implement a more general block.

In addition to private email blacklists, there are lists that are kept for public use, including:

Web browsing

[edit]

The goal of a blacklist in a web browser is to prevent the user from visiting a malicious or deceitful web page via filtering locally. A common web browsing blacklist is Google's Safe Browsing, which is installed by default in Firefox, Safari, and Chrome.

Usernames and passwords

[edit]

Blacklisting can also apply to user credentials. It is common for systems or websites to blacklist certain reserved usernames that are not allowed to be chosen by the system or website's user populations. These reserved usernames are commonly associated with built-in system administration functions. Also usually blocked by default are profane words and racial slurs.

Password blacklists are very similar to username blacklists but typically contain significantly more entries than username blacklists. Password blacklists are applied to prevent users from choosing passwords that are easily guessed or are well known and could lead to unauthorized access by malicious parties. Password blacklists are deployed as an additional layer of security, usually in addition to a password policy, which sets the requirements of the password length and/or character complexity. This is because there are a significant number of password combinations that fulfill many password policies but are still easily guessed (i.e., Password123, Qwerty123).

Distribution methods

[edit]

Blacklists are distributed in a variety of ways. Some use simple mailing lists. A DNSBL is a common distribution method that leverages the DNS itself. Some lists make use of rsync for high-volume exchanges of data.[6] Web-server functions may be used; either simple GET requests may be used or more complicated interfaces such as a RESTful API.

Examples

[edit]
  • Companies like Google, Symantec and Sucuri keep internal blacklists of sites known to have malware and they display a warning before allowing the user to click them.
  • Content-control software such as DansGuardian and SquidGuard may work with a blacklist in order to block URLs of sites deemed inappropriate for a work or educational environment. Such blacklists can be obtained free of charge or from commercial vendors such as Squidblacklist.org.
  • There are also free blacklists for Squid (software) proxy, such as Blackweb
  • A firewall or IDS may also use a blacklist to block known hostile IP addresses and/or networks. An example for such a list would be the OpenBL project.
  • Many copy protection schemes include software blacklisting.
  • The company Password RBL offers a password blacklist for Microsoft's Active Directory, web sites and apps, distributed via a RESTful API.
  • Members of online auction sites may add other members to a personal blacklist. This means that they cannot bid on or ask questions about your auctions, nor can they use a "buy it now" function on your items.
  • Yet another form of list is the yellow list which is a list of email server IP addresses that send mostly good email but do send some spam. Examples include Yahoo, Hotmail, and Gmail.[citation needed] A yellow listed server is a server that should never be accidentally blacklisted. The yellow list is checked first and if listed then blacklist tests are ignored.
  • In Linux modprobe, the blacklist modulename entry in a modprobe configuration file indicates that all of the particular module's internal aliases are to be ignored. There are cases where two or more modules both support the same devices, or a module invalidly claims to support a device.
  • Many web browsers have the ability to consult anti-phishing blacklists in order to warn users who unwittingly aim to visit a fraudulent website.
  • Many peer-to-peer file sharing programs support blacklists that block access from sites known to be owned by companies enforcing copyright. An example is the Bluetack[7] blocklist set.

Usage considerations

[edit]

As expressed in a recent conference paper focusing on blacklists of domain names and IP addresses used for Internet security, "these lists generally do not intersect. Therefore, it appears that these lists do not converge on one set of malicious indicators."[8][9] This concern combined with an economic model[10] means that, while blacklists are an essential part of network defense, they need to be used in concert with whitelists and greylists.

Controversy over terminology

[edit]
See also: Inclusive language

Some major technology companies and institutions have publicly distanced themselves from the term blacklist due to a perceived connection with racism, instead recommending the terms denylist or blocklist.[11][12][13][14][15][16] The term's connection with racism, as well as the value in avoiding its use has been disputed.[15][17][better source needed]

Controversy over use of the term

[edit]

In 2018, a journal commentary on a report on predatory publishing[18] was released which claimed that "white" and "black" are racially-charged terms that need to be avoided in instances such as "whitelist" and "blacklist", and that the first recorded usage of "blacklist" was during "the time of mass enslavement and forced deportation of Africans to work in European-held colonies in the Americas". The article hit mainstream in Summer 2020 following the George Floyd protests in America.[19]

A number of technology companies replaced "whitelist" and "blacklist" with new alternatives such as "allow list" and "deny list", alongside similar terminology changes regarding the terms "Master" and "Slave".[20] For example, in August 2018, Ruby on Rails changed all occurrences of "blacklist" and "whitelist" to "restricted list" and "permitted list".[21] Other companies responded to this controversy in June and July 2020:

  • GitHub announced that it would replace many "terms that may be offensive to developers in the black community".[22]
  • Apple Inc. announced at its developer conference that it would be adopting more inclusive technical language and replacing the term "blacklist" with "deny list" and the term "whitelist" with "allow list".[23]
  • Linux Foundation said it would use neutral language in kernel code and documentation in the future and avoid terms such as "blacklist" and "slave" going forward.[24]
  • The Twitter Engineering team stated its intention to move away from a number of terms, including "blacklist" and "whitelist".[25]
  • Red Hat announced that it would make open source more inclusive and avoid these and other terms.[26]

ZDNet reports that the list of technology companies making such decisions "includes Twitter, GitHub, Microsoft, LinkedIn, Ansible, Red Hat, Splunk, Android, Go, MySQL, PHPUnit, Curl, OpenZFS, Rust, JP Morgan, and others."[27]

The issue and subsequent changes caused controversy in the computing industry, where "whitelist" and "blacklist" are prevalent (e.g. IP whitelisting[28]). Those[who?] that oppose these changes question the term's attribution to race, claiming that the term "blacklist" arose from the practice of using black books in medieval England.[20]

References

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Blacklist (computing)

View on Grokipedia
from Grokipedia
In computing, a blacklist is an access control mechanism comprising a list of discrete entities—such as IP addresses, domains, senders, or software—that have been identified as linked to malicious activities, thereby denying them access to systems, networks, or services. This approach contrasts with whitelisting, which permits only pre-approved entities, by default allowing all except the explicitly blocked ones, making it a reactive tool reliant on prior threat intelligence. Blacklists find widespread application in cybersecurity domains, including to combat spam via real-time blackhole lists (RBLs) that flag abusive IP addresses, firewall configurations to block known threat sources, and to recognized malware signatures. For instance, in systems, domain-based blacklists target domains to reduce unsolicited messages, while network administrators employ them to restrict access from compromised or hostile endpoints. Their implementation often integrates with tools like DNS-based lookups for efficient, scalable enforcement against distributed threats. While blacklists effectively mitigate known risks by leveraging collective reporting from threat feeds, they are hampered by significant limitations, including high rates of false positives that erroneously block legitimate traffic and false negatives that overlook emerging or evasive threats not yet cataloged. Studies reveal issues like outdated entries and incomplete coverage, with some blacklists achieving only partial spam detection alongside notable error rates, prompting ongoing refinements such as dynamic thresholding to balance and . These characteristics underscore blacklists' role as a foundational yet imperfect layer in layered defense strategies, where accuracy depends on vigilant maintenance and diverse data sources.

Definition and Fundamentals

Core Principles and Purpose

A blacklist in computing constitutes a predefined list of discrete entities—such as IP addresses, domains, senders, applications, or processes—previously identified as untrustworthy, unauthorized, or malicious, which are systematically denied access, execution, or processing within a system. This exclusionary mechanism operates on the principle of reactive denial, relying on accumulated of threat behaviors to filter out known risks, thereby implementing a form of negative where default permission is overridden only for matched entries. The core purpose of blacklisting is to mitigate causal risks from repeated or patterned adversarial actions, such as spam dissemination, propagation, or unauthorized intrusions, by preemptively blocking interactions that could lead to resource compromise or operational disruption. Unlike permissive models, it prioritizes efficiency against high-volume, identifiable threats through simple , enabling scalable enforcement in resource-constrained environments like firewalls or gateways. This approach assumes that documented malicious histories provide reliable indicators for future prevention, though its effectiveness hinges on timely updates to reflect evolving tactics.

Comparison to Whitelists and Greylists

Blacklists operate on a default-permit , explicitly denying access to identified threats such as malicious IP addresses or domains, whereas whitelists enforce a default-deny approach by permitting only pre-approved entities, thereby blocking all unknowns. This fundamental contrast influences their efficacy: blacklists are reactive, targeting known risks like those cataloged in real-time DNS-based blackhole lists (DNSBLs) for , but they fail against novel threats, as attackers can evade by using unlisted IPs or domains. Whitelists, conversely, provide stronger proactive defense in controlled environments, such as application whitelisting in enterprise endpoints, where only verified software executes, reducing zero-day exploit risks by up to 99% in some implementations. Greylists introduce a behavioral intermediary, temporarily deferring or quarantining suspicious entities for verification, often exploiting the tendency of legitimate systems to retry connections while many automated spam or attack tools do not. In email spam filtering, greylisting—first proposed in a 2003 method by —rejects initial SMTP connections from unknown senders, accepting retries after a delay (typically 5-10 minutes), which can filter 50-90% of spam without permanent blocks. This hybrid mitigates blacklist maintenance burdens and whitelist rigidity but introduces latency for valid traffic and potential failures if compliant senders lack retry logic.
AspectBlacklistWhitelistGreylist
PolicyAllow by default; block known badDeny by default; allow known goodDefer unknowns for verification
ProsLow maintenance for common threats; minimal disruption to legitimate trafficHigh security against unknowns; limits Reduces spam volume via behavior; avoids exhaustive lists
ConsMisses emerging threats; lists bloat over timeHigh false positives for new legit items; requires ongoing curationDelays delivery; ineffective against persistent attackers
Best UseBroad network/ (e.g., DNSBLs)Strict environments (e.g., endpoint app control) MTA defenses (e.g., Postfix integration)
Empirical data from analyses indicate whitelists outperform blacklists in preventing unauthorized code execution, as evidenced by reduced incidents in whitelisted systems, though blacklists remain prevalent due to in high-volume scenarios like web filtering. Greylisting complements both by adding a low-overhead filter layer, particularly in resource-constrained servers, but its effectiveness diminishes against sophisticated bots that implement retries, as observed in post-2010 spam trends. Selection depends on context: blacklists suit permissive, threat-known domains; whitelists fit high-stakes, static setups; greylists enhance dynamic protocols like SMTP.

Historical Development

Origins in Networking and Early Security Practices

TCP Wrappers, introduced by Wietse Venema in 1990, represented one of the earliest formalized implementations of in Unix-based . Developed initially to monitor and log connections amid rising intrusions on networked workstations at , the tool wrapped around inetd-managed services to enforce host-based access controls. It employed two configuration files: /etc/hosts.allow for explicit permissions and /etc/hosts.deny as a deny list, blocking connections from specified IP addresses, hostnames, or domains unless overridden by allow rules. This blacklist mechanism operated on a default-permit model, allowing all traffic except that matching deny entries, which facilitated reactive blocking of known threats like crackers probing for vulnerabilities in services such as FTP or . Venema's design included logging capabilities to identify attack patterns, enabling administrators to populate deny lists dynamically based on observed malicious activity. By 1992, the approach was documented in detail, emphasizing its role in simple yet effective perimeter defense before dedicated firewalls became widespread. Preceding TCP Wrappers, early network security in and nascent TCP/IP environments (from the 1970s) relied on informal practices like null-routing suspicious hosts or manual daemon reconfiguration, but lacked standardized deny lists. The shift toward explicit blacklists in tools like TCP Wrappers addressed the limitations of trust-based models, as interconnected Unix systems faced increasing unauthorized access attempts in the late . This laid groundwork for broader adoption in , influencing later systems despite eventual supersession by stateful firewalls and IP-level filtering.

Expansion in the Internet Era (1990s–2000s)

The proliferation of spam email in the mid-, coinciding with the and rapid expansion of the , necessitated the development of systematic mechanisms to filter unwanted at scale. Early efforts relied on manually maintained text files shared among network administrators, but these proved inadequate as spam volumes surged from thousands to millions of messages daily by the late . A pivotal advancement occurred in 1997 with the creation of the Real-time Blackhole List (RBL), the first Domain Name System-based Blackhole List (DNSBL), developed by under the Mail Abuse Prevention System (MAPS). This system enabled servers to query a centralized for reversed IP addresses of known spam sources; a matching response would trigger rejection of incoming mail, automating blocking without exhaustive local lists. Initially operated as a private resource, the RBL gained public adoption rapidly, influencing major ISPs and mail transfer agents by blocking traffic from dynamically assigned dial-up IPs commonly abused by spammers. In 1998, was founded in by Steve Linford as a non-profit initiative to track and list spam operations, expanding blacklisting to include policy-based criteria such as open relays and domains hosting spamware. Spamhaus's blocklists, including the Spamhaus Block List (SBL) for manual spam source entries, quickly complemented DNSBLs by distributing data to over 100 million servers worldwide by the early 2000s, reducing global spam delivery rates through collaborative reporting from operators and users. The 2000s saw further proliferation of DNSBL operators, such as the Open Relay Database (ORDB) in 1998 and distributed systems like SpamCop, which integrated user-submitted reports with automated verification to list IPs responsible for up to 80% of reported spam incidents. This era's blacklists extended beyond email to rudimentary IP-level controls for network abuse, including early implementations of BGP route blackholing for , though remained the dominant application. Adoption metrics indicated that by 2005, over 70% of enterprise email gateways referenced multiple DNSBLs, correlating with a measurable decline in deliverability for listed sources, from near-universal to sub-10% in some cases.

Technical Implementation

Underlying Data Structures and Algorithms

Blacklists in computing typically employ hash sets or hash tables as primary data structures for storing entries such as IP addresses, domains, or email hashes, enabling average O(1) time complexity for lookups, insertions, and deletions, which is critical for high-throughput security applications like real-time traffic filtering. These structures map entries to fixed-size buckets via hash functions, minimizing collision resolution overhead through techniques like or , though they require more memory than alternatives for very large sets. For memory-constrained environments or massive-scale blacklists—such as those containing millions of IP addresses or URLs—Bloom filters provide a probabilistic alternative, representing sets as bit arrays tested via multiple hash functions to query membership with no false negatives but potential false positives tunable by size and hash count. Invented by Burton Howard Bloom in 1970, this excels in by reducing storage needs; for instance, firewalls use Bloom filters to blacklist IPs, achieving rapid unauthorized access detection without exhaustive storage of full entries. Web browsers like apply them to dangerous URL blacklists, balancing query speed against acceptable error rates. Algorithms for blacklist operations prioritize efficiency in dynamic scenarios: insertion hashes the entry and updates the structure (e.g., setting bits in a or adding to a hash set bucket), while deletion in exact-match structures like hash sets involves locating and removing the entry, though lack true deletion, necessitating variants like counting or periodic rebuilds. Query algorithms perform hashed lookups, with computing k hash values (typically 3–10) to check bit positions, yielding false positive rates as low as 1% for optimized parameters in IP reputation systems. Advanced management incorporates predictive elements, such as statistical learning to prioritize prolific attackers in blacklists, enhancing coverage in intrusion response by focusing on high-impact sources rather than exhaustive enumeration. In domain or IP range blacklisting, hybrid approaches may integrate tries (prefix trees) with hash sets for hierarchical matching, such as CIDR blocks or domain suffixes, allowing efficient prefix queries in O(length of key) time, though pure hash sets suffice for exact matches prevalent in most implementations. Update algorithms often involve merging feeds via union operations, with real-time protocols diffing changes to minimize overhead in distributed systems. These choices reflect causal trade-offs: hash-based structures favor speed over perfect accuracy in probabilistic cases, grounded in empirical performance metrics from deployments where lookup latency directly impacts threat mitigation efficacy.

Enforcement and Query Mechanisms

Enforcement of blacklists in systems typically occurs at runtime during access attempts, where matching entities—such as IP addresses, domains, or file hashes—are identified and blocked to prevent unauthorized or malicious interactions. In network firewalls, enforcement involves inspecting incoming packets or connection requests against a blacklist; if a source IP matches, the firewall drops the packets or terminates the session without further processing, thereby isolating the system from known threats. This reactive mechanism relies on predefined rules integrated into the firewall's policy engine, often updated via periodic synchronization with external feeds. Similarly, in servers, enforcement integrates with SMTP protocols, where upon receiving a connection from a suspicious sender, the server halts message acceptance and issues a rejection if the sender's IP is blacklisted. Query mechanisms for blacklists emphasize efficiency to minimize latency in high-volume environments, commonly employing DNS-based lookups for distributed services like DNSBLs (DNS Blacklists). For an such as 192.0.2.1, the querying system reverses the octets to form a (1.2.0.192.dnsbl.example.com) and performs a DNS A-record query; a response resolving to a specific IP range, such as 127.0.0.2 indicating spam activity, confirms listing and triggers enforcement. These queries occur in real-time during the initial SMTP or HTTP request preprocessing, with caching mechanisms to reduce repeated DNS resolutions and avoid rate-limiting by blacklist providers. Local blacklists, stored in hash tables or Bloom filters for probabilistic fast lookups, enable sub-millisecond queries without external dependencies, though they require frequent updates to maintain accuracy against evolving threats. In web content filtering and proxy servers, query mechanisms extend to domain and URL blacklists, where client requests are parsed and checked against remote APIs or embedded databases before proxying traffic; matches result in HTTP 403 errors or redirects to block pages. Advanced implementations incorporate behavioral analysis alongside static queries, such as monitoring connection patterns to dynamically enforce blacklists, but core reliance remains on deterministic matching to ensure causal prevention of known risks. Overall, these mechanisms balance speed and comprehensiveness, with DNSBLs handling millions of daily queries across global mirrors for redundancy.

Applications in Computing Systems

Email and Messaging Security

In email security, blacklists primarily function through DNS-based blocklists (DNSBLs), also known as realtime blackhole lists (RBLs), which maintain directories of IP addresses and domains associated with spam, , distribution, or compromised infrastructure. Mail transfer agents (MTAs) query these lists via DNS reverse lookups during the SMTP transaction; if the sender's IP resolves to a listed entry, the email is rejected or quarantined, serving as an automated pre-filter to reduce inbound threats before . The Spamhaus Blocklist (SBL), for instance, identifies IPs actively sending spam or hosting malicious content, with real-time updates enabling rapid response to emerging abuse patterns. DNSBLs originated with the first RBL deployment in 1997, initially leveraging (BGP) routing announcements before shifting to DNS queries for scalability in spam mitigation amid rising unsolicited volumes. Major operators like Spamhaus process billions of daily queries, blocking an estimated 80-90% of spam at the network edge when integrated with other filters, though empirical studies indicate coverage gaps, with some reputation-based lists detecting only 24% of spam while incurring 34% false positives on legitimate traffic. False positives arise from dynamic IP reassignment or temporary compromises, prompting operators to implement delisting procedures and hybrid approaches combining blacklists with whitelists for precision. In phishing defense, and domain blacklists complement IP checks by flagging known malicious links in bodies, with analyses showing that while blacklists exhibit low false positive rates (under 1% in controlled datasets), they suffer high false negatives, missing up to 98% of novel threats due to evasion tactics like . Effectiveness improves when layered with behavioral heuristics, as standalone blacklists lag against fast-flux networks where attackers rotate IPs to bypass listings. For messaging security beyond email, blacklists extend to SMS and instant messaging protocols, where carrier-level or app-integrated lists block numeric sender IDs linked to smishing (SMS phishing) or premium fraud, often drawing from shared threat intelligence feeds similar to DNSBLs. Enterprise deployments frequently blacklist high-risk messaging apps like or Signal variants due to data exfiltration risks, prioritizing controlled channels over consumer tools with unverified end-to-end encryption implementations. However, evasion persists via disposable numbers or encrypted payloads, limiting blacklist utility without endpoint verification.

Web Browsing and Content Filtering

In web browsing, blacklists serve as a primary defense mechanism to block access to URLs associated with , , or other threats by comparing requested sites against maintained lists of known harmful domains. Browsers such as and integrate services like , which distributes updated blacklists of suspicious URLs to clients for local or server-side verification before page loads, preventing users from encountering deceptive content that could lead to data theft or infection. This approach relies on real-time updates from centralized providers scanning billions of URLs daily to identify patterns of malicious activity, such as embedded scripts or redirects to exploit kits. Content filtering extends blacklist applications beyond security threats to enforce policy-based restrictions, categorizing and blocking sites deemed inappropriate for specific environments like schools, workplaces, or homes. Systems compare URLs against category-specific blacklists—covering adult content, , or —using databases curated by threat intelligence firms to deny access proactively. For instance, enterprise tools in Defender for Endpoint enable administrators to block predefined categories, logging attempts for compliance while allowing granular overrides. In practice, web proxies and browser extensions enforce these blacklists by intercepting HTTP/HTTPS requests and matching them against blocklists, often combining exact matches with domain wildcards for broader coverage. Providers like maintain dynamic lists classified by content type, integrated into firewalls and browsers to filter traffic at the network edge, reducing exposure to non-compliant or risky resources without requiring endpoint modifications. This method supports scalable deployment in large organizations, where blacklists update via protocols like DNS or feeds to reflect emerging threats.

Network and IP-Level Controls

Network and IP-level controls in blacklisting involve compiling and querying lists of IP addresses linked to malicious behaviors, such as spam dissemination, botnet command-and-control, or DDoS attacks, to enforce access denial at the network perimeter. Firewalls, routers, and intrusion prevention systems (IPS) integrate these blacklists to inspect packet headers and drop traffic originating from or destined to listed IPs before it reaches internal hosts, thereby reducing exposure to threats without relying on higher-layer protocol analysis. This approach leverages the IP protocol's addressing for coarse-grained filtering, prioritizing speed and scalability in high-volume environments. A primary implementation uses DNS-based blackhole lists (DNSBLs), where systems reverse the querying IP (e.g., 192.0.2.1 becomes 1.2.0.192) and append the blacklist's domain zone for an A record lookup; a positive response (typically IP 127.0.0.x) confirms listing and triggers blocking. This mechanism, standardized in RFC 5782, allows distributed querying without direct database access, enabling real-time checks during connection attempts. Enforcement occurs via ACLs in devices like or Palo Alto firewalls, where threat intelligence feeds populate dynamic block lists for automated updates. Prominent providers include Spamhaus, whose Blocklist (SBL) as of 2023 covers over 10 million IPs daily associated with spam sources, compromised hosts, or abusive networks, achieving block rates exceeding 90% for known spam in integrated systems. Other feeds, such as those from or emerging threat repositories, categorize IPs by threat type (e.g., malware C2 or scanning), allowing nuanced policies like rate-limiting versus outright drops. In large deployments, such as ISP edge routers, blacklists integrate with BGP flowspec to propagate blocks across autonomous systems, mitigating distributed attacks. Effectiveness stems from causal linkage between listed IPs and observed attacks, with empirical studies showing DNSBLs reducing inbound by 50-80% in mail relays when combined with scoring. However, controls must handle dynamic IP allocation in NAT environments, where legitimate users share blacklisted addresses, necessitating delisting appeals and hybrid whitelisting. Integration with SDN controllers further automates propagation, as seen in enterprise fabrics enforcing uniform policies across segments.

Software and Access Restrictions

Application blacklisting, also known as blocklisting, involves maintaining a list of prohibited software, executables, or files that are denied execution or installation on a to enforce access restrictions. This approach permits all other applications by default while explicitly blocking identified threats or unauthorized programs, contrasting with whitelisting which requires explicit approval for execution. In enterprise environments, blacklisting is often implemented via policy engines that scan file hashes, paths, or publisher certificates against the deny list before allowing runtime. In Windows, policies support through deny rules that override allow rules and prevent specified executables, scripts, or packaged apps from running, regardless of user privileges. Introduced in Enterprise and Server 2008 R2, 's deny actions enable targeted restrictions, such as blocking legacy or unverified software in corporate deployments, with enforcement modes allowing audit-only testing before full activation. Similarly, older Software Restriction Policies (SRP) in Windows provided path- or hash-based to prevent unauthorized execution, though offers more granular control via publisher and . On mobile platforms, blacklisting facilitates by allowing guardians to block specific applications on children's devices. , for instance, enables parents to remotely limit or prohibit app usage on Android devices linked to a child's account, integrating with to restrict downloads and runtime access. Apple's on and similarly permits blacklisting of apps deemed inappropriate, enforcing downtime or content restrictions based on age ratings or custom lists, with data from September 2025 indicating widespread adoption for managing over 4.5 million devices via Family Link alone. Antivirus and endpoint detection tools frequently employ for real-time software restrictions, scanning against databases of known malicious signatures or behaviors to or delete prohibited files. This method, while reactive, requires frequent updates to counter evolving threats, as unlisted novel can evade detection until identified and added. In deny-by-exception policies, such as those aligned with NIST SP 800-171, identifies and blocks non-authorized software across organizational systems.

Distribution and Maintenance

Centralized Services and Providers

The Spamhaus Project stands as a leading centralized provider of DNS-based blacklists (DNSBLs) for combating spam, malware distribution, and botnet command-and-control infrastructure. Established in 1998 as a non-profit organization initially in London and later relocated to Andorra, Spamhaus maintains authoritative lists through manual verification and analysis of reported abuse data, rather than relying solely on automated or crowdsourced inputs. Its core offerings include the Spamhaus Block List (SBL), which targets static IP addresses directly involved in spam transmission; the Extended Block List (XBL), focused on exploited compromised hosts; and the Policy Block List (PBL), which restricts dynamic and poorly managed IP ranges prone to abuse. These are aggregated into the ZEN blocklist, queried via DNS for real-time enforcement, reportedly blocking over 800 million spam sources daily as of 2023 data. Spamhaus's operations emphasize proactive threat intelligence, drawing from global reports and proprietary monitoring to list entries with evidence of repeated violations, such as sending unsolicited bulk exceeding 100 messages per IP or facilitating campaigns. Delisting requires demonstrated remediation, like securing infected systems or implementing anti-spam policies, with an average processing time of 24-48 hours for valid requests. The service is free for non-commercial use but offers paid data feeds for enterprises, powering filters in major email providers and firewalls worldwide. However, its aggressive listing criteria have drawn and lawsuits from operators claiming overreach, including a 2013 U.S. ruling that temporarily disrupted operations due to distributed denial-of-service attacks allegedly funded by listed entities. Other notable centralized providers include SpamCop, acquired by Cisco Systems in 2017, which generates short-term blocklist entries (typically 24-72 hours) based on user-submitted spam reports analyzed against trap networks and heuristics. This service prioritizes high-confidence spam sources, integrating with mail transfer agents for immediate rejection of matching traffic. ' Reputation Block List (BRBL) employs on behavioral data from its global sensor network to score and blacklist IPs exhibiting spam-like patterns, such as rapid volume surges or invalid recipient queries, with listings valid until reputation improves. UCEPROTECT Level 1 and 2 lists, maintained by a German-based group since 2002, focus on open relays and dial-up pools but have been critiqued for indiscriminate range-based blocking, affecting legitimate users without granular appeals. These providers contrast with decentralized models by centralizing decision authority, enabling consistent policy enforcement but raising concerns over transparency in listing algorithms.

Collaborative and Decentralized Models

Collaborative blacklisting models involve multiple organizations or entities sharing threat data, such as firewall logs or attack alerts, to collectively generate and maintain dynamic lists of malicious IP addresses, domains, or other identifiers. For instance, DShield.org operates as a collaborative where participants voluntarily submit daily firewall logs, enabling the correlation of attack patterns to produce IP blacklists used for predictive threat forecasting. This approach leverages aggregated data from diverse sources to improve detection accuracy, as demonstrated in studies analyzing large-scale log contributions, which reveal common attack vectors like scanning behaviors preceding exploits. Collaborative predictive blacklisting (CPB) extends this by using on shared logs to anticipate future attackers, with evaluations showing reduced false negatives compared to isolated , though privacy concerns necessitate controlled sharing mechanisms like . In email and , collaborative models underpin services like DNS-based blackhole lists (DNSBLs), where operators aggregate reports from global contributors to list IPs associated with spam or abuse, queried via DNS for real-time enforcement. Examples include systems that process submissions from network administrators and users, correlating them to update lists dynamically, with hit rates varying by contributor volume—higher participation correlates with broader coverage of transient threats like botnets. Such models distribute maintenance burden while enhancing resilience, as no single entity monopolizes data, but they require validation protocols to mitigate biased or erroneous inputs from participants. Decentralized blacklisting shifts from centralized aggregation to distributed ledgers or architectures, often employing for immutable, consensus-driven updates to lists of threats like URLs or malicious nodes. PhishChain, proposed in 2022, exemplifies this by using a where participants vote on URL blacklisting via smart contracts, ensuring transparency and resistance to single-point tampering, with simulations indicating faster consensus than traditional databases for high-volume reports. In ecosystems, models like those for detecting attacks maintain blacklists of malicious pools through decentralized judgment strategies, combining node attestations to isolate repeat offenders without a trusted intermediary. Similarly, BLOCIS integrates for sharing, storing blacklisted indicators in tamper-proof blocks verified by proof-of-quality consensus, which empirical tests show sustains data integrity across untrusted networks. These systems address centralization risks, such as censorship or downtime, by distributing validation, though they introduce computational overhead from consensus mechanisms, with latency increases of up to 20-30% in prototypes under load. Hybrid approaches blend collaboration with , as in -enhanced threat sharing platforms that incentivize contributions via while enforcing quality through peer verification, reducing reliance on authoritative sources prone to delays or biases. Evaluations of such frameworks highlight improved evasion resistance, as distributed updates propagate faster than centralized feeds, but remains challenged by throughput limits, with proposals like layer-2 solutions mitigating this for real-time applications. Overall, these models prioritize causal robustness by grounding listings in verifiable, multi-source evidence, fostering broader adoption in peer networks where trust is emergent rather than imposed.

Update Protocols and Real-Time Feeds

Update protocols for blacklists in computing systems ensure that lists of blocked entities, such as or domains, remain current against evolving threats like spam sources or command-and-control servers. These protocols typically involve a combination of on-demand querying and periodic synchronization mechanisms, where consuming systems either poll blacklist providers for updates or receive pushed notifications of new entries. For instance, DNS-based blacklists (DNSBLs) rely on real-time DNS queries, in which a reversed is appended to the provider's domain (e.g., querying 1.2.3.4.sbl.spamhaus.org for IP 4.3.2.1) to check status against the provider's dynamically maintained database, enabling immediate enforcement without local list storage. This approach leverages the DNS protocol's low-latency resolution, with providers updating their zones multiple times per day to reflect newly identified threats. Real-time feeds extend these capabilities through structured data exchange formats and APIs, delivering machine-readable indicators of compromise (IOCs) such as fresh IP blacklists or domain blocks via protocols like HTTP/ APIs, streams, or specialized standards including TAXII (Trusted Automated eXchange of Indicator Information). platforms, for example, provide continuous streams of updated IOCs, often refreshed hourly or more frequently to capture rapid threat evolution, allowing automated ingestion into firewalls, gateways, or endpoint protection tools. Services like Spamhaus maintain real-time databases for spam and exploit-related IPs, while others such as SURBL offer real-time feeds (RTF) alongside for bulk synchronization of blacklists used in and web filtering. These feeds prioritize actionable, low-false-positive data derived from honeypots, trap reporting, and collaborative networks, though depends on the provider's verification processes to avoid propagating unconfirmed entries. Challenges in implementation include balancing update frequency with resource overhead, as excessive polling can strain DNS infrastructure, prompting alternatives like DNS Response Policy Zones (RPZ) for caching and faster local resolution of blacklist hits. Empirical data from providers indicates that real-time mechanisms reduce exposure windows to minutes for high-confidence threats, but require robust delisting procedures—such as manual appeals or automated timeouts—to mitigate errors from dynamic IP assignments or legitimate activity misclassification.

Challenges and Effectiveness

False Positives and Error Rates

False positives in blacklists occur when legitimate entities, such as IP addresses, domains, or email senders, are erroneously included on lists intended to block malicious activity, leading to unintended disruptions like blocked legitimate emails or restricted access to benign websites. This error stems from factors including the use of dynamic IP assignments, shared hosting environments where one compromised user affects others, and automated listing criteria that prioritize speed over precision, resulting in overblocking. Empirical analyses indicate that false positive rates vary significantly across blacklists, with some exhibiting rates as low as 0.2% but others reaching up to 9.5% in contexts, highlighting the trade-off between detection efficacy and accuracy. In DNS-based blacklists (DNSBLs) for email filtering, studies of providers like Spamhaus, SpamCop, and SORBS have measured false positive rates through controlled tests on verified legitimate traffic, revealing discrepancies: for instance, one evaluation found an aggregate 0.74% false positive rate when combining multiple lists, while SORBS alone showed rates up to 10% due to broader inclusion of potentially graylisted IPs. For URL and malware blacklists, false positives arise from heuristic matching or reputation scoring that misclassifies dynamic content or legitimate high-traffic sites, with research on reputation-based systems reporting "higher than expected" error rates when evaluated against ground-truth benign samples. These rates are often lower in precision-tuned lists like Spamhaus's SBL, which self-reports "extremely low" false positives through manual review processes, though independent studies confirm variability tied to update frequency and listing thresholds. Mitigation strategies include delisting appeals, hybrid approaches integrating whitelists, and dynamic thresholding to adjust sensitivity based on patterns, which one study showed could reduce false positives by refining cluster-based detections in network-level blacklists. Overall, while blacklists achieve high spam capture rates (e.g., 91% in combined use), persistent false positives underscore the need for ongoing empirical validation, as unchecked errors can erode user trust and prompt workarounds like IP rotation.

Adversarial Evasion Techniques

Adversarial evasion techniques refer to methods employed by malicious actors to circumvent blacklist-based defenses in environments, such as DNS blacklists (DNSBLs), IP reputation lists, and blocklists used for spam filtering, command-and-control (C2) disruption, and restriction. These techniques exploit the inherent delays in blacklist updates, the static nature of many lists, and gaps in detection coverage, allowing threats to persist despite widespread adoption of blacklisting. For instance, blacklists like Spamhaus or SURBL rely on community reporting and verification, which can take hours or days, providing windows for evasion. One prominent technique is fast flux DNS, where attackers rapidly cycle the IP addresses (and sometimes nameservers) associated with a domain, often changing every few minutes, to distribute traffic across compromised or proxy hosts and hinder blacklisting of fixed indicators. This method, observed in botnets and phishing campaigns since the mid-2000s, evades traditional DNSBLs by ensuring no single IP accumulates enough abuse reports for listing before rotation. The U.S. (CISA) highlighted fast flux in 2025 as a technique used by groups for resilient C2 infrastructure, noting its role in threats by complicating takedown efforts. Domain generation algorithms (DGAs) enable to procedurally generate thousands of pseudo-random domain names daily based on seeds like or hardcoded parameters, with attackers registering only a for C2 communication. This dynamic approach defeats static blacklists, as defenders cannot predict or enumerate all possible domains in advance; for example, DGAs in families like or Bedep produce over 50,000 variants per day, overwhelming manual blocking. ATT&CK documentation classifies DGAs as a sub-technique for dynamic domain resolution (T1568.002), emphasizing their use in evading denylisting by creating a moving target that persists even if individual domains are identified and blocked. Akamai reports that DGAs prevent server denylisting by mimicking legitimate randomization while maintaining synchronization between infected hosts and attacker-controlled endpoints. In email spam campaigns, distributes low-volume messages across numerous IP addresses and domains—often rented or compromised—to stay below per-source thresholds that trigger blacklist inclusion. This "snowshoe" pattern, akin to spreading weight over a wide area, evades reputation-based filters like those from Spamhaus, as no single sender generates detectable spam rates; campaigns may use hundreds of IPs sending under 1% of total volume each. Spamhaus has documented snowshoe operations rotating domains and employing content evasion like image-based spam to further dilute signals. Mimecast notes that this technique scales by combining it with subdomain spoofing, complicating mitigation as blacklists struggle with distributed, low-signal abuse. For URL blacklists in web filtering, adversaries employ obfuscation and redirection, such as URL shorteners (e.g., bit.ly proxies), hexadecimal/IP literal encoding, or multi-stage redirects, to mask malicious endpoints from static blocklists. Shorteners create intermediate links not present on lists, delaying categorization until post-click analysis, while encodings bypass keyword-based filters; Menlo Security reported in 2024 that such tactics allow threats to evade URL categorization tools by exploiting decoding delays in proxies. Additionally, legacy URL reputation evasion (LURE) leverages compromised legitimate sites—previously vetted as safe—to host payloads, inheriting the host's clean reputation until detection lags. Dark Reading described "ghost hosts" in 2017 as a variant where malware swaps blacklisted domains for unlisted ones via DNS manipulation, prolonging access before filters update. Bulletproof hosting (BPH) services further enable evasion by providing infrastructure in jurisdictions resistant to takedown requests, often ignoring abuse reports and using IP blocks that rotate to avoid . These providers, such as those sanctioned by the U.S. in 2025 for aiding , employ techniques like frequent ASN changes and lenient policies to host or without triggering lists like Spamhaus Exploits Blocklist. A 2017 IEEE study on BPH detection found providers registering and abandoning network blocks rapidly, evading IP-based blacklists and delaying enforcement; Resecurity linked BPH to operations like in 2025, noting their role in sustaining global threats despite sanctions. These techniques underscore blacklists' limitations against adaptive adversaries, prompting shifts toward behavioral and real-time threat intelligence, though static lists remain foundational due to their low false-positive rates in verified scenarios. Empirical data from sources like ' indicate DGAs alone sustain 10-20% of analyzed families, highlighting ongoing efficacy challenges.

Scalability in Large-Scale Deployments

In large-scale deployments, such as those in internet service providers (ISPs) or cloud environments handling millions of daily queries, blacklists encounter significant scalability hurdles related to storage requirements and lookup latency. Exact-match data structures like hash tables for storing millions to billions of entries—such as IP addresses or URLs—can consume substantial memory, often scaling linearly with list size and leading to gigabytes or terabytes of RAM per node in distributed systems. Query throughput must remain sub-millisecond to avoid bottlenecking network traffic, yet naive implementations degrade performance under peak loads from high-volume traffic analysis. Probabilistic data structures, particularly s, mitigate these issues by enabling space-efficient membership testing with constant-time operations. A represents a set using a and multiple hash functions, requiring approximately 10 bits per element for a below 1%, allowing storage of billions of blacklist entries in megabytes rather than gigabytes. For instance, in web filtering applications, s facilitate rapid checks against prohibited content lists, with scalable variants dynamically expanding by adding sub-filters to accommodate growth without rebuilding the entire structure. This approach supports distributed caching in systems like , where additional hash checks per sub-filter maintain performance across shards. Despite these advantages, trade-offs persist in ultra-large deployments. False positives, inherent to probabilistic methods, necessitate confirmatory lookups for potential matches, increasing CPU overhead if the rate exceeds 0.1%; tuning requires balancing bits per item against memory budgets. Bloom filters are append-only, complicating deletions for dynamic blacklists, often addressed via counting variants or periodic rebuilds, which introduce update latency in real-time environments. In network contexts, such as DNS-based blacklists (DNSBLs), scalability relies on query-efficient protocols and infrastructure. Services like Spamhaus DNSBL handle real-time updates for millions of spam-sending IPs with low-bandwidth DNS resolutions, leveraging routing and client-side caching to distribute load across global resolvers without centralized bottlenecks. Enterprise networks face additional challenges with IP blacklists due to address sharing (e.g., via ) and frequent attacker IP rotation, requiring hybrid approaches combining probabilistic pre-filters with exact verification to avoid over-blocking legitimate traffic.

Controversies and Criticisms

Debate Over Terminology (Blacklist vs. Blocklist)

The term "blacklist" has been conventionally used in since at least the mid-20th century to denote a list of entities—such as IP addresses, domains, or email senders—deemed untrustworthy or prohibited from access, originating from non-racial historical contexts like 17th-century lists of suspected individuals under monarchs such as Charles II. Around 2020, amid broader corporate initiatives to revise technical lexicon for perceived inclusivity, "blocklist" emerged as a proposed alternative, with advocates arguing it avoids potential negative associations of "black" with exclusion or harm, even absent direct etymological ties to race. Proponents of the shift, including figures in digital advertising and , contend that "blocklist" is more descriptively precise—directly conveying the action of blocking—while fostering environments free from language that could inadvertently evoke bias in diverse teams, a priority amplified by events like the 2020 protests. Tech firms such as instructed developers in July 2020 to prefer "blocklist" and "allowlist" over "blacklist" and "whitelist" in Chrome projects, while and integrated similar guidelines into their style guides by late 2020, citing neutrality as enhancing collaboration. These changes reflect a pattern in tech where DEI-influenced policies prioritize symbolic linguistic reforms, though empirical evidence linking such terms to actual remains anecdotal rather than data-driven. Critics, including security practitioners and commentators skeptical of overreach, maintain that rebranding is superfluous since "blacklist" derives from neutral archival traditions—such as "" of criminal records—without inherent racial valence in technical usage, and altering entrenched terms disrupts codebases, searches, and industry without measurable benefits. Practical drawbacks include fragmented across tools, where "blacklist" retains dominance in legacy systems and open-source projects, potentially confusing users and reducing in searches; for instance, providers like Abusix noted in 2021 that no consensus exists on alternatives like "denylist," leading to inconsistent adoption. Opponents further argue the debate exemplifies sensitivity-driven changes in tech sectors prone to institutional biases favoring progressive norms over functional clarity, as evidenced by uneven enforcement—major providers like Spamhaus continue using "blacklist" as of 2023 without backlash. As of 2024, usage remains divided: "blacklist" prevails in most cybersecurity literature and tools, comprising over 80% of references in technical databases per informal surveys, while "blocklist" appears in newer corporate codebases and vendor marketing, underscoring a lack of driven more by internal policies than user demand or efficacy gains. This terminological variance highlights tensions between preserving precise, historical and accommodating subjective inclusivity concerns, with no peer-reviewed studies demonstrating improved outcomes from the switch.

Impacts on Privacy and False Blocking

Blacklists in computing, particularly IP and domain blacklists used for spam and malware mitigation, can inadvertently block legitimate traffic through false positives, where non-malicious entities are listed due to algorithmic errors, shared infrastructure, or outdated data. A 2008 empirical study analyzing over 1 million emails from a network of 7,000 hosts found non-trivial false positive rates across major blacklists: exhibited up to 26.9% for unique source IPs, SpamCop 13.6%, SpamHaus 5.2%, and NJABL 0.2%, with SpamAssassin used as an oracle for ham classification. These errors often stem from dynamic IP assignments or (NAT), where one compromised device taints an entire , denying service to unaffected users. For instance, blacklisted six Google mail servers in 2008, disrupting delivery of legitimate emails from users. False blocking extends to domain blacklists, where legitimate sites suffer from association with abusive subdomains or prior owners. Businesses relying on for operations report revenue losses from blacklisting, as outbound communications fail and inbound leads are filtered, with delisting processes sometimes taking weeks due to opaque criteria from providers like Spamhaus. A 2023 evaluation of IP blacklists across European networks found lower false positive incidences in modern deployments, with no overlaps between clean IPs (high cyberscores) and listings from sources like or , suggesting improvements in precision via better data sources and . However, persistent challenges include adversarial misreporting by competitors or automated traps, amplifying overblocking in high-volume environments like web filtering. Privacy implications arise from the data collection underpinning blacklists, which often involves aggregating traffic logs, IP traces, and behavioral signals from network operators, potentially enabling of user activities . Such aggregation can lead to "inferential guilt," where entities are penalized based on probabilistic associations rather than , with limited transparency or appeal mechanisms exacerbating deficits. IP-based blacklisting, in particular, compromises user since addresses link to ISPs and geolocations, allowing third-party maintainers to profile endpoints; shared IPs in residential or environments further erode individual by imposing collective restrictions. While blacklist operators like Spamhaus claim anonymized feeds, the underlying monitoring raises surveillance risks, as feeds are queried in real-time DNS lookups that reveal querying parties' interests. Empirical data on breaches remains sparse, but causal links to access denial highlight how blacklists prioritize aggregate threat reduction over granular protections, sometimes at the expense of non-malicious users' .

Empirical Evidence on Overall Efficacy

Empirical studies indicate that blacklists achieve moderate to high against persistent or repeat threats in spam filtering, with DNS-based blacklists (DNSBLs) covering over 80% of identified spam sources in analyses of from 2004, where aggressive lists like and DSBL listed thousands of hosts responsible for the majority of spam volume. Aggregated blacklists and whitelists together accounted for more than 85% of spam messages in sender datasets, demonstrating substantial blocking of known malicious IPs. However, efficacy diminishes against low-profile or short-lived spam sources, which evade listing due to limited connection volumes or rapid IP rotation, with such sources rising notably in observed patterns. In IP-based threat mitigation, blacklists detect approximately 50% of scanner IPs and associated malicious activities across monitored networks, including service providers and universities, but false negative rates remain high as lists prioritize precision to avoid over-blocking legitimate traffic. For instance, combinations of prominent blacklists like Emerging Threats and DShield achieve only marginal improvements in recall, leaving significant scanning and attack traffic unblocked, particularly for web servers (73% coverage) versus mail servers (42%). This precision-recall trade-off results in blacklists functioning as a partial barrier rather than comprehensive protection, underscoring their role in layered defenses. For malware domain blocking, public blacklists cover fewer than 20% of domains associated with prevalent families in real-world samples, while antivirus vendor lists reach over 70% coverage overall, exceeding 90% for several families like . Detection delays vary, with some lists like Abuse.ch resolving 80% of listings within one week, but others exceeding 30 days for over half of entries, limiting utility against fast-evolving campaigns. Quality issues, such as inclusion of parked or non-existent domains (up to 85% in certain lists), further erode effectiveness, though vendor-maintained lists demonstrate superior timeliness and completeness for command-and-control infrastructure. Phishing blacklists exhibit low immediate efficacy against novel sites, with tests on 191 freshly discovered phishing URLs under 30 minutes old revealing minimal detections across eight major lists, highlighting lags in listing that allow short-lived attacks to propagate before blocking. Repeat offenders represent only a small fraction of phishing domains, reducing the proportional impact of blacklists on one-time campaigns, though they effectively target recurring . Across contexts, blacklists reduce exposure by 40-80% for established actors but falter against evasion via or zero-day tactics, necessitating complementary behavioral and approaches for holistic efficacy.

References

  1. https://csrc.nist.gov/glossary/term/blacklist
  2. https://www.twingate.com/blog/glossary/blacklist
  3. https://instasafe.com/blog/whitelisting-vs-blacklisting-whats-the-difference/
  4. https://www.knowledgehut.com/blog/security/blacklisting-in-cyber-security
  5. https://mxtoolbox.com/blacklists.aspx
  6. https://www.campaignmonitor.com/blog/email-marketing/email-blacklists-101-what-you-need-to-know/
  7. https://www.indusface.com/learning/what-is-ip-blacklisting/
  8. https://www.paulgraham.com/falsepositives.html
  9. https://liu.engin.umich.edu/wp-content/uploads/sites/56/2018/04/PAM2013.pdf
  10. https://www.researchgate.net/publication/224354096_Shades_of_grey_On_the_effectiveness_of_reputation-based_blacklists
  11. https://faculty.cc.gatech.edu/~mbailey/publications/ndss10_final.pdf
  12. https://www.esecurityplanet.com/applications/whitelisting-vs-blacklisting-which-is-better/
  13. https://www.binadox.com/blog/application-security-understanding-blacklisting-vs-whitelisting-approaches/
  14. https://www.cisco.com/c/en/us/td/docs/security/firepower/60/configuration/guide/fpmc-config-guide-v60/Security_Intelligence_Blacklisting.pdf
  15. https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-167.pdf
  16. https://www.zenarmor.com/docs/network-security-tutorials/what-is-blacklisting-whitelisting-and-greylisting
  17. https://www.cloudns.net/blog/whitelisting-vs-blacklisting-preventing-reacting/
  18. https://www.goallsecure.com/blog/blacklisting-vs-whitelisting-vs-greylisting/
  19. https://www.usenix.org/legacy/publications/library/proceedings/sec92/full_papers/venema.pdf
  20. https://www.ituonline.com/tech-definitions/what-are-tcp-wrappers/
  21. https://unix.stackexchange.com/questions/710532/which-takes-precedence-etc-hosts-allow-or-firewalld
  22. https://www.usenix.org/legacyurl/highly-predictive-blacklisting
  23. https://www.suped.com/guides/blocklists/a-brief-history-of-email-blacklists-and-blocklists
  24. https://www.usdatacorporation.com/marketing-insights/blacklist/
  25. https://blog.mxtoolbox.com/2019/08/29/4183/
  26. https://www.prolateral.com/help/kb/smtp/491-what-is-dnsbl.html
  27. https://arkiv.internetdagarna.se/2000/spam/maps/history.html
  28. https://www.spamhaus.org/history/
  29. https://mailrelay.com/en/glossary/spamhaus/
  30. https://www.emailondeck.com/b/DNSBL-Because-Spam-is-the-Real-Black-Hole-of-the-Internet
  31. https://www.dnsbl.info/
  32. https://stackoverflow.com/questions/7910130/most-efficient-way-of-implementing-a-blacklist
  33. https://gencmurat.com/en/posts/bloom-filters/
  34. https://celerdata.com/glossary/bloom-filters
  35. https://gwern.net/doc/cs/security/2013-geravand.pdf
  36. https://ieeexplore.ieee.org/document/7299960/
  37. https://ita.ucsd.edu/workshop/10/files/paper/paper_159.pdf
  38. https://news.ycombinator.com/item?id=32186203
  39. https://www.sciencedirect.com/science/article/abs/pii/S0167404815000966
  40. https://medium.com/capital-one-tech/blazing-fast-data-lookup-in-a-microservices-world-dd3ae548ca45
  41. https://docs.aws.amazon.com/ses/latest/dg/faqs-dnsbls.html
  42. https://www.spamhaus.org/resource-hub/email-security/dns-blocklist-basics/
  43. https://www.invaluement.com/how-it-works/
  44. https://dl.acm.org/doi/10.1145/1315245.1315288
  45. https://www.spamhaus.org/blocklists/exploits-blocklist/
  46. https://www.spamhaus.com/resource-center/ip-based-dns-blocklists-dnsb-ls-for-email-filtering/
  47. https://stalw.art/docs/spamfilter/dnsbl
  48. https://www.spamhaus.org/blocklists/spamhaus-blocklist/
  49. https://paulgraham.com/falsepositives.html?viewfullsite=1
  50. https://www.brandsec.com.au/are-ip-blacklists-and-rbls-still-relevant/
  51. https://www.researchgate.net/publication/228932769_An_Empirical_Analysis_of_Phishing_Blacklists
  52. https://arxiv.org/pdf/2308.08356
  53. https://dnschecker.org/ip-blacklist-checker.php
  54. https://www.helpnetsecurity.com/2017/10/04/top-blacklisted-apps/
  55. https://www.darkreading.com/mobile-security/messenger-apps-top-risk-hit-parade
  56. https://seosly.com/blog/google-safe-browsing/
  57. https://infinitynetwork.com/what-is-google-safe-browsing/
  58. https://learn.microsoft.com/en-us/defender-endpoint/web-content-filtering
  59. https://www.fortinet.com/resources/cyberglossary/what-is-url-filtering
  60. https://documentation.meraki.com/MX/Content_Filtering_and_Threat_Protection/Content_Filtering
  61. https://support.google.com/chrome/a/answer/9942583?hl=en
  62. https://www.imperva.com/learn/application-security/ip-blacklist/
  63. https://datatracker.ietf.org/doc/html/rfc5782
  64. https://docs.paloaltonetworks.com/ngfw/help/10-2/monitor/monitor-block-ip-list/block-ip-list-entries
  65. https://www.techtarget.com/searchsecurity/definition/application-blacklisting
  66. https://learn.microsoft.com/en-us/windows/security/application-security/application-control/app-control-for-business/applocker/understanding-applocker-allow-and-deny-actions-on-rules
  67. https://learn.microsoft.com/en-us/windows/security/application-security/application-control/app-control-for-business/applocker/working-with-applocker-rules
  68. https://std.rocks/windows_grouppolicy_blockapplications.html
  69. https://support.google.com/families/answer/7103028?hl=en
  70. https://support.apple.com/en-us/105121
  71. https://play.google.com/store/apps/details?id=com.google.android.apps.kids.familylink&hl=en_US
  72. https://www.runnetworkrun.com/security-info/application-whitelisting-vs-blacklisting-choosing-the-right-security-approach/
  73. https://csf.tools/reference/nist-sp-800-171/r2/3-4/3-4-8/
  74. https://www.spamhaus.org/who-is-spamhaus/
  75. https://www.spamhaus.com/solutions/email-and-network/email-protection/
  76. https://www.spamhaus.org/blocklists/zen-blocklist/
  77. https://www.spamhaus.org/resource-hub/ip-reputation/what-does-spamhaus-do/
  78. https://ccronline.sigcomm.org/wp-content/uploads/2019/02/sigcomm-ccr-final215.pdf
  79. https://www.usenix.org/system/files/conference/cset13/cset13-sonchack.pdf
  80. https://arxiv.org/abs/1810.02649
  81. https://arxiv.org/abs/1502.05337
  82. https://www.ionos.com/digitalguide/server/know-how/dnsbl/
  83. https://international.eco.de/news/selecting-a-dnsbl/
  84. https://arxiv.org/pdf/2202.07882
  85. https://link.springer.com/article/10.1007/s11227-022-04370-1
  86. https://www.mdpi.com/2079-9292/9/3/521
  87. https://www.researchgate.net/publication/368495874_Blockchain-Based_Cyber_Threat_Intelligence_Sharing_Using_Proof-of-Quality_Consensus
  88. https://www.recordedfuture.com/threat-intelligence-101/intelligence-sources-collection/threat-intelligence-feeds
  89. https://hoxhunt.com/blog/threat-intelligence-feeds
  90. https://www.surbl.org/surbl-analysis
  91. https://faculty.cc.gatech.edu/~mbailey/publications/malware08_final.pdf
  92. https://repository.upenn.edu/bitstreams/3da0249c-e24d-4df7-a079-c55ebde46f8b/download
  93. https://web.eecs.umich.edu/~zmao/Papers/ndssZhiyun2010.pdf
  94. https://www.spamhaus.org/
  95. https://www.cisa.gov/news-events/cybersecurity-advisories/aa25-093a
  96. https://www.blackfog.com/fast-fluxing-attacks-explained/
  97. https://attack.mitre.org/techniques/T1568/002/
  98. https://www.akamai.com/glossary/what-are-dgas
  99. https://www.spamhaus.org/resource-hub/spam/a-snowshoe-winter-our-discontent-with-can-spam/
  100. https://www.mimecast.com/content/snowshoe-spam/
  101. https://www.menlosecurity.com/blog/url-shortening-allows-threats-to-evade-url-filtering-and-categorization-tools
  102. https://www.darkreading.com/vulnerabilities-threats/-ghost-hosts-bypass-url-filtering
  103. https://ieeexplore.ieee.org/document/7958611
  104. https://www.resecurity.com/fr/blog/article/qilin-ransomware-and-the-ghost-bulletproof-hosting-conglomerate
  105. https://unit42.paloaltonetworks.com/threat-brief-understanding-domain-generation-algorithms-dga/
  106. https://aerospike.com/blog/taking-advantage-of-probabilistic-data-structures/
  107. https://www.geeksforgeeks.org/system-design/bloom-filters-in-system-design/
  108. https://aws.amazon.com/blogs/database/implement-fast-space-efficient-lookups-using-bloom-filters-in-amazon-elasticache/
  109. https://softwareengineering.stackexchange.com/questions/184205/how-do-scalable-bloom-filters-work
  110. https://hackernoon.com/understanding-bloom-filters-an-efficient-probabilistic-data-structure
  111. https://www.adexchanger.com/data-driven-thinking/no-more-inflammatory-jargon-change-blacklist-to-blocklist/
  112. https://seattlecollegian.com/op-ed-blacklist-and-whitelist-arent-racist-words-you-are/
  113. https://abusix.com/blog/why-changing-the-terms-blacklist-and-whitelist-isnt-as-easy-as-it-might-seem/
  114. https://hodigital.blog.gov.uk/2020/07/23/not-a-black-and-white-issue-using-racially-neutral-terms-in-technology/
  115. https://www.suped.com/guides/blocklists/the-difference-between-a-blacklist-and-a-blocklist
  116. https://scholarship.law.ufl.edu/cgi/viewcontent.cgi?article=1289&context=flr
  117. https://www.spamhaus.org
  118. http://conferences.sigcomm.org/imc/2004/papers/p370-jung.pdf
  119. https://wisr.cs.wisc.edu/papers/spam-comsnets.pdf
  120. https://christian-rossow.de/publications/blacklists-raid2014.pdf
  121. https://www.semanticscholar.org/paper/660d1003d04c2ca4f621dc581e9586b9d141c619
Add your contribution
Related Hubs
User Avatar
No comments yet.