# apache-ultimate-bad-bot-blocker: a blocklist measured in thousands of referrers > The Apache Ultimate Bad Bot Blocker is not a program but a set of Apache configuration files and blocklists, maintained as a git repository so it can be updated like code. It ships two variants, one for Apache 2.2 and one for 2.4, because the access control syntax changed and the older variant needs a compatibility module loaded. **mitchellkrogza/apache-ultimate-bad-bot-blocker** — Apache Block Bad Bots, (Referer) Spam Referrer Blocker, Vulnerability Scanners, Malware, Adware, Ransomware, Malicious Sites, Wordpress Theme Detectors and Fail2Ban Jail for Repeat Offenders - Repository: https://github.com/mitchellkrogza/apache-ultimate-bad-bot-blocker - Stars: 984 · Forks: 199 - Language: C - License: NOASSERTION - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/mitchellkrogza-apache-ultimate-bad-bot-blocker ## What the blocklists actually contain The readme publishes the size of the data, and the numbers are the story. The current version is labelled V3.2026.10.2752, and the counts are 7115 bad referrers, 699 bad bots and 218 fake Googlebots. Each count links to the corresponding list file in a generator lists directory in the repository, so the lists are versioned with the configuration and you can read exactly what is in them. The fake Googlebot list is the most interesting of the three, and the reason for it is worth spelling out. A large share of the traffic that looks like a search engine crawler is not one. Anyone can set a user agent string, and the people selling scraped data and fake engagement set theirs to Googlebot because the label is trusted. A list of 218 known fakes is a way of filtering that population that a generic user agent list would miss. The referrer list is much larger than the bot list, and that reflects a different problem. Referrer spam is the traffic that arrives with a link to a gambling site, a pharmaceutical site or a payday loan service, and it exists to create backlinks that a domain owner will never see but a crawler might. 7115 entries is a lot of accumulated reports, which is the strength of the list and also its maintenance cost. So the project is three related things: a bad bot list, a fake crawler list and a referrer list, plus the Apache configuration that applies them. The readme's own summary of the scope is broader, covering adware, malware, ransomware, clickjacking, click redirecting, bad IPs, an anti-DDoS system, nginx rate limiting and a WordPress theme detector blocker, and the topic list adds a gambling filter, a porn filter and a Fail2Ban jail for repeat offenders. ## Two versions, because the access control syntax changed The readme puts a warning at the top about there being two distinctly different versions, and the reason is a piece of Apache history that catches people out. The original version, for Apache 2.2 through 2.4, requires the access_compat module and uses the older Order Allow,Deny access control methods. It lives in a directory named for Apache 2.2 in the repository, and it is described as the original version of the blocker. The new version is for Apache 2.4 only and uses the newer access control structures of RequireAll and RequireAny. The readme says anyone using Apache 2.4 should use the new version, because it fully complies with the new access control methods of Apache and does not require the access_compat module to be loaded. That is a real decision with real consequences. The two access control systems behave differently when a request matches several directives, and mixing them produces the kind of configuration where one rule silently wins. The readme also records the versions each was tested on, Apache 2.2 through 2.4.27 for the older one and Apache 2.4 through 2.4.34 for the newer one. So the choice is not really a preference. If your server is on 2.4, use the 2.4 variant and you get clean RequireAny semantics with no extra module. If you are stuck on 2.2, the older variant is what exists, and you need to confirm the compatibility module is loaded. ## Installing is one file in a custom directory The installation is short, and the design decision to put the rules in an include file is the part that makes updates painless. The instruction is to copy the globalblacklist.conf file from the repository into your Apache configuration's custom.d folder, and the readme notes that Apache's configuration directory is generally at /etc/apache2 or /etc/httpd depending on the operating system. On Ubuntu and Debian that is /etc/apache2/custom.d, and on RHEL and CentOS it is /etc/httpd. The folder has to be created, because it does not exist by default. ```bash sudo mkdir /etc/apache2/custom.d ``` Then the file is fetched directly from the repository: ```bash sudo wget https://raw.githubusercontent.com/mitchellkrogza/apache-ultimate-bad-bot-blocker/master/Apache_2.2/custom.d/globalblacklist.conf -O /etc/apache2/custom.d/globalblacklist.conf ``` And if your distribution has no wget, the curl equivalent is given: ```bash curl -sL https://raw.githubusercontent.com/mitchellkrogza/apache-ultimate-bad-bot-blocker/master/Apache_2.2/custom.d/globalblacklist.conf -o /etc/apache2/custom.d/globalblacklist.conf ``` The paths in those examples point at the 2.2 directory, so you change the path segment to match the variant you decided on. The reason for the include file is stated later in the instructions: whitelisting is done using include files so that you do not have to keep reinserting your whitelisted domains and IP addresses every time you update. That is the whole maintenance model in one sentence. The blocklist is regenerated and replaced wholesale, and your own exceptions live in a separate file that the update does not touch. There is also an install script and an update script at the root of the repository, so the whole procedure can be scripted rather than typed. ## Whitelisting your own site is the step that matters Step two of the configuration is the one that will decide whether your week goes well or badly, and the readme marks it with a warning. You whitelist all your own domain names and IP addresses, and the readme flags that this is now done using include files, so that you do not have to reinsert them every time you update the blocklist. The failure mode is obvious once you think about it. A site that blocks a referrer list of more than seven thousand entries will, sooner or later, contain an entry that matters to you, and if you have not whitelisted your own domains and addresses, the block will apply to your own monitoring, your own uptime checks, your own search console crawls and any service of yours that identifies itself with a referrer header. The order of the instructions is also instructive. Copy the file first, whitelist second, and only then consider it configured. A blocker that is installed without a whitelist is the classic way to lose an afternoon to a mysterious outage that turns out to be your own monitoring being blocked at the door. The same reasoning applies to the reverse direction. The project also blocks by IP, and the readme asks you to whitelist your own IP addresses, which is a slightly different case, since an address that is yours today may not be tomorrow's, and because the bad IP list is the one that changes your site's behaviour for legitimate visitors with a shared address. ## The paths for people who do not control the server A large part of the repository exists for people who cannot install an Apache module or edit the server configuration, and the readme is explicit about which instruction file to read. There is a cPanel instructions directory, because a lot of shared hosting runs cPanel, and a Plesk Onyx instructions directory for the other common control panel. There is a directory of htaccess versions, and the readme points users who are unable to run the full blocker there, along with a note that it includes an htaccess file and a robots.txt file for users without root access to their Apache servers. There is a directory of OpenLiteSpeed htaccess files, a separate set of rules for that server rather than for Apache. The robots.txt file is a separate top level entry, and a robots.txt is a request to well behaved crawlers, which is the opposite of what a blocker does. Both exist because they are different instruments: the robots file asks for restraint politely, and the blocklist enforces it. Keeping the two in the same project is sensible as long as you understand that the robots file does nothing against a hostile client. The rest of the top level is supporting machinery. There is a generator lists directory holding the source lists, a fail2ban addon directory for the jail that repeats offenders, a directory for finding fake Googlebots, a Google Analytics ghost spam directory, a Google Webmaster disavow links directory, a latest-release directory, developer tools, and a vendored zlib copy. There is also a configuration document and a separate readme for the cPanel and htaccess paths. ## Version drift, and what to trust in the repository There is a discrepancy in the repository worth knowing about before you rely on any of it. The readme declares the current version as V3.2026.10.2752, and the last push was on 2026-10-19, so the working tree is current. The tagged releases, however, stop at V3.2021.06.1210, from June 2021, with the two before it in May 2021 and June 2021. That means the tags are stale while the branch is not, and the consequence for you is concrete. If you clone the master branch you get the current configuration, but if you pin to a tag you get a 2021 snapshot whose blocklists are five years out of date, which for a list of this kind is most of the value gone. The readme handles the updates in the way you would expect: it asks you to subscribe to GitHub notifications so you are told when the blocker is updated or when an important, potentially breaking change happens. That is an admission that an update can break your site, which is true of any change to a large set of access rules, and it is the reason to keep the whitelist in a separate file. The licence is a custom one in a file named LICENSE.md, and the repository is classified as unrecognised by GitHub, so read that file rather than assuming a standard open source licence. The author is Mitchell Krog, and the project is funded through sponsorship, a coffee page, and a note that South Africa is not yet supported by the GitHub sponsor programme, so sponsorship is arranged by email. ## Conclusion The Apache Ultimate Bad Bot Blocker suits a site owner on shared hosting or with a plain Apache server who wants a maintained blocklist they can update with a pull rather than hand edit, and who is willing to keep a whitelist of their own domains and addresses. It is a poor fit if you run nginx or a CDN in front of Apache, since the rules are Apache access control directives, and a poor fit if you want per-request intelligence rather than static lists. Before you install it, read the whitelist section all the way through, because the failure mode is your own monitoring and your own crawlers being blocked, and pick the variant that matches your Apache version and your access control syntax. ## FAQ ### Which version of the Apache bad bot blocker should I install? The 2.4 variant if you run Apache 2.4, because it uses the RequireAll and RequireAny access control structures and does not need the access_compat module. The original variant, kept in the Apache_2.2 directory, is for Apache 2.2 through 2.4 and uses the older Order Allow,Deny methods. ### How do I install the Apache bad bot blocker? Create a custom.d directory inside your Apache configuration directory, at /etc/apache2/custom.d on Ubuntu and Debian or /etc/httpd on RHEL and CentOS, then download the globalblacklist.conf file from the repository into it. Whitelist your own domain names and IP addresses afterwards, using include files so your entries survive an update. ### What is in the bad bot blocker's lists? The readme publishes the counts for the current version: 7115 bad referrers, 699 bad bots and 218 fake Googlebots. Each list lives as a file in the generator lists directory, so the data is versioned alongside the configuration and can be read before you install it. ### Can I use the blocker without root access to my Apache server? Yes. The readme points users who cannot run the full blocker to a set of htaccess versions, and the repository also includes instructions for cPanel and for Plesk Onyx, an OpenLiteSpeed set of htaccess files, and an htaccess file plus a robots.txt file for shared hosting where you cannot touch the server configuration. ## Sources - [Issues](https://github.com/mitchellkrogza/apache-ultimate-bad-bot-blocker/issues) - [mitchellkrogza/apache-ultimate-bad-bot-blocker on GitHub](https://github.com/mitchellkrogza/apache-ultimate-bad-bot-blocker) - [README](https://github.com/mitchellkrogza/apache-ultimate-bad-bot-blocker/blob/master/README.md) - [Releases](https://github.com/mitchellkrogza/apache-ultimate-bad-bot-blocker/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mitchellkrogza-apache-ultimate-bad-bot-blocker