drmaxnix/fuckai repository overview

Source Code: git.tjdev.de/DrMaxNix/fuckai⁠

⁠fuckai - A Prototype for the fckai Project

Docker Web Application Firewall (WAF) for Protecting Web Apps against AI Scrapers

⁠How It Works

1. Your server stack consists of these three components:
   • the reverse proxy, which will terminate SSL connections and forward traffic to the fuckai container
   • the fuckai container, which will either forward traffic to the application container, or present a challenge page
   • the application container
2. The challenge page will be displayed if the client does not present a valid key cookie
3. The key is essentially a signed combination of the client's ip address and a time component (either changing daily or weekly)
4. To obtain this key from the fuckai api, the challenge page contains a few lines of JavaScript that the client needs to execute (and optionally click a button to run it)

⁠Setup Instructions

⁠1. Set up fuckai

Add the fuckai service to your docker-compose.yml, mount your host system's timezone files and point it to your application container:

services:
  fuckai:
    image: drmaxnix/fuckai:1
    restart: unless-stopped
    environment:
      APPLICATION_HOST: "app"
    volumes:
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    ports:
      - 127.0.0.1:80:80
  
  app:
    # ...

⁠2. Configure your reverse proxy

Now point your reverse proxy at port 80 of the fuckai container.

⁠Configuration Options

Following configuration options are available by setting environment variables:

⁠List of Available Key Types

The key that allows the client temporary access to the application is built from multiple components. Generally, it always contains a secret component, which will be regenerated at each container start. All components will then be hashed to basically create a signed form of all non-secret components. Selecting the right components to build the key is crucial in determining when clients will be presented with the challenge page again. Or in other words: they determine how long and for which client a single key is valid. Following component combinations are currently available:

⁠List of Available Challenge Types

To separate bots from living creatures, we ask visitors to do a challenge. Depending on how eagerly you want to do this separation, you can pick from multiple challenges with varying difficulty. Following challenges are currently available:

⁠Allowlist files

To prevent losing SEO or breaking APIs, certain paths can be added to a whitelist, which will cause these paths to always be allowed, regardless of whether a valid key has been provided or not. For this, there are three files that can be mounted into the container:

• /allow-str.txt: List of allowed paths (exact match)
• /allow-beg.txt: List of allowed path prefixes
• /allow-reg.txt: List of allowed path regex patterns

If you have these files set up and saved in the same directory as your docker-compose.yml, you can simply mount them into the container as follows:

services:
  fuckai:
    # ...
    volumes:
      # ...
      - ./allow-str.txt:/allow-str.txt:ro
      - ./allow-beg.txt:/allow-beg.txt:ro
      - ./allow-reg.txt:/allow-reg.txt:ro

⁠Example allowlist files

allow-str.txt:

# allow robots and sitemap files
/robots.txt
/sitemap.xml

# allow home page for seo
/

# allow the about main page
/about

allow-beg.txt:

# allow all api calls
/api/

# allow all files in the .well-known directory
/.well-known/

# allow all files in the assets directory
/assets/

# allow the about sub-pages
/about/

allow-reg.txt:

# allow user profile pages
^/user/[a-z0-9_-]+$

⁠Allowlist file presets

• Gitea⁠

⁠Attribution / Credits

• Inter (OFL 1.1⁠): https://github.com/rsms/inter⁠