You can also check the traditional chinese version (中文版).
Just discovered that my wiki was taken down again. From the access logs, it looks like a bot scanning through proxies. This time, relying only on the Caddy Defender Plugin wasn’t enough. Suddenly thought that for this kind of attack, using DNSBL might help.
First, I used DNSBL Information to check several IP addresses against different DNSBLs to see which one fits best. The one I found is SpamRATS, and their RATS-Spam (spam.spamrats.com) seems suitable to use.
I also looked for projects related to Caddy and found a relatively new project called caddy-matcher-dnsbl that supports DNSBL filtering. After installing and testing, it seems to work, and the number of blocked requests is quite good.
So, this adds another method to our cocktail approach of defense.
Update: To add some notes on how to use multiple DNSBLs—the official documentation doesn’t mention this, but I confirmed it by looking into the code:
wiki.gslin.org {
@dnsbl dnsbl {
providers "b.barracudacentral.org." "spam.spamrats.com."
}
respond @dnsbl 403
}
The 403 status code can be replaced with other 4xx codes, which helps you identify blocked requests from the access logs. Also, you can use sudo tcpdump -i any -n port 53 to monitor DNS queries made to the DNSBL servers.
Finally, some DNSBLs block common public DNS servers like 1.1.1.1 and 8.8.8.8; running a local Unbound DNS server usually resolves this issue.