Anti-spam DNSBL by BOates [CHANGES REQUIRED TO WORK WITH SPAMASSASSIN 3.4.2 or later in v76+]
This functionality must be updated to work with SpamAsasssin 3.4.2 or it will break all mail delivery on cPanel v76+ : Anti-spam DNSBL by BOates [CHANGES REQUIRED TO WORK WITH SPAMASSASSIN 3.4.2 or later in v76+]
I've put together a new anti-spam DNSBL that I feel fills a current gap in the existing anti-spam block lists out there. I'm looking for some individuals whom run cPanel servers to add the DNSBL to their configuration and see how it fares, as a sort of beta test.
THE PROBLEM
I've personally observed a growing trend with spammers involving short lived domains. They register a brand new domain, ensure that a valid SPF record, valid PTR (RDNS) record, and sometimes even valid DKIM are setup. Then they blast out mail for a few hours/days, and abandon the domain before it's effectively evaluated by existing anti-spam block lists.
The spam I've been getting from this spammer technique has even registered a negative score from SpamAssassin (meaning it is inclined to believe it's definitely good email).
THE RESPONSE
How am I attacking this technique? Essentially, the DNSBL I've put together blocks any domain name that were registered less than 5 days ago. Once the domain ages past 5 days, it automatically expires from the block list.
Now, you may be familiar with a DNSBL that attempts to fulfill this very need already. SpamEatingMonkey's "Fresh" DNSBL. The problem is, I've tried it. In fact, attempting to use SEM's Fresh DNSBL is what prompted me to produce my own DNSBL because it was only catching about 1 in 50 fresh domains, sometimes even a much worse effectiveness ratio.
STATISTICS
I've been running this on my own personal machine for just under a month, which has a handful of personal use domains.
2015-03-20 => 2015-04-12
Emails Blocked by my DNSBL: 8,326
Emails Blocked by SpamHaus/Barracuda: 3,525
Emails Blocked by SpamAssassin: 266
Emails Delivered to inboxes: 3,870
RISKS
As I'm sure is painfully obvious to everyone, the risk here is that the DNSBL does not make any attempt to discern from a legitimate new internet user deploying their brand new shiny domain versus a devious spammer abusing freshly registered domains. Both are unilaterally blocked until their domains are 5 days old.
The difference is that the legitimate user will keep using their domain after 5 days, whereas the spammer will have long since abandoned their (now widely recognized and blacklisted) domain. Since this block list requires no de-listing (all domains auto-delist after the domain is over 5 days old), it's at least a short lived temporary problem at best.
I may look into a forced early-delist if legitimate customers are finding this too much of a problem, but the early-delist option could be abused by spammers as well, of course.
INTERESTED?
Well, hopefully I've piqued your interest. That's my goal here so I can test in more real world scenarios and see if it's as effective as I seem to find on my own personal box. This DNSBL is still in early stages of testing, though. It could very well fall flat on its face and be unscalable in its current form. That's why I need your help with testing it.
If you'd like help test it, follow the below steps:
1.) SSH into your server as root and create/edit the following file:
/usr/local/cpanel/etc/exim/perl/trimdomain
2) Copy/Paste the below code inside and save it (This has been updated to SpamAssassin 3.4.1+)
3.) Still on the server as root, create/edit the following file: /usr/local/cpanel/etc/exim/acls/ACL_MAIL_POST_BLOCK/custom_begin_mail_post 4.) Copy/Paste the below code inside and save it
5.) Make Exim rebuild its exim.conf to include the two changes we made by running: /scripts/buildeximconf 6.) Restart Exim by running: /scripts/restartsrv_exim 7.) When the DNSBL rejects a message, you will see log output in /var/log/exim_mainlog that looks similar to below: 2015-04-13 10:14:22 H=(ftj09.freezebloodsugarcure.ninja) [192.200.201.9]:47300 rejected MAIL : Fresh Domain Blocked - [freezebloodsugarcure.ninja] is listed on (fresh.dieinafire.com)
8.) Done! You're now utilizing the DNSBL. Please post some feedback if you do decide to test it out. UNINSTALL 1.) Remove the file: /usr/local/cpanel/etc/exim/perl/trimdomain 2.) Remove the snippet previously added to the file: /usr/local/cpanel/etc/exim/acls/ACL_MAIL_POST_BLOCK/custom_begin_mail_post 3.) Rebuild exim.conf by running: /scripts/buildeximconf 4.) Restart Exim by running: /scripts/restartsrv_exim 5.) The DNSBL is now entirely uninstalled FAQ Q: Will this block my new customers from sending out email? A: Not on your end. The exim.conf entry ignores authenticated users, which permits your own server's users to send email outbound even if their own domain is less than 5 days old. However, if the receiving server is using this same DNSBL, they'll be blocked from delivering to that server. As mentioned, once their domain is over 5 days old they'll auto-delist from the block list. TROUBLESHOOTING Q: In exim_mainlog, I see: 2015-04-13 12:13:05 DNS list lookup defer (probably timeout) for domain.tld.fresh.dieinafire.com: assumed not in list
A: Something is blocking you from running a DNS Lookup against the DNSBL *or* your DNS Queries are taking far too long to resolve. This could be a problem on your end *or* my DNSBL's end (one of the reasons I'm trying to load test it). Verify that you can query the DNSBL directly by running: dig +short test.fresh.dieinafire.com It should return '127.0.0.2' like below: # dig +short test.fresh.dieinafire.com 127.0.0.2
If it just returns to a blank prompt, then something is wrong and either your DNS resolvers in /etc/resolv.conf are causing problems or some firewall settings are at fault.
sub trimdomain {
require Mail::SpamAssassin::RegistryBoundaries;
my $domain = shift;
my $rb = new Mail::SpamAssassin::RegistryBoundaries;
return $rb->trim_domain($domain);
}
3.) Still on the server as root, create/edit the following file: /usr/local/cpanel/etc/exim/acls/ACL_MAIL_POST_BLOCK/custom_begin_mail_post 4.) Copy/Paste the below code inside and save it
drop
!authenticated = *
dnslists = fresh.dieinafire.com/${perl{trimdomain}{$sender_address_domain}}
message = Fresh Domain Blocked - [${perl{trimdomain}{$sender_address_domain}}] is listed on (fresh.dieinafire.com)
5.) Make Exim rebuild its exim.conf to include the two changes we made by running: /scripts/buildeximconf 6.) Restart Exim by running: /scripts/restartsrv_exim 7.) When the DNSBL rejects a message, you will see log output in /var/log/exim_mainlog that looks similar to below: 2015-04-13 10:14:22 H=(ftj09.freezebloodsugarcure.ninja) [192.200.201.9]:47300 rejected MAIL : Fresh Domain Blocked - [freezebloodsugarcure.ninja] is listed on (fresh.dieinafire.com)
8.) Done! You're now utilizing the DNSBL. Please post some feedback if you do decide to test it out. UNINSTALL 1.) Remove the file: /usr/local/cpanel/etc/exim/perl/trimdomain 2.) Remove the snippet previously added to the file: /usr/local/cpanel/etc/exim/acls/ACL_MAIL_POST_BLOCK/custom_begin_mail_post 3.) Rebuild exim.conf by running: /scripts/buildeximconf 4.) Restart Exim by running: /scripts/restartsrv_exim 5.) The DNSBL is now entirely uninstalled FAQ Q: Will this block my new customers from sending out email? A: Not on your end. The exim.conf entry ignores authenticated users, which permits your own server's users to send email outbound even if their own domain is less than 5 days old. However, if the receiving server is using this same DNSBL, they'll be blocked from delivering to that server. As mentioned, once their domain is over 5 days old they'll auto-delist from the block list. TROUBLESHOOTING Q: In exim_mainlog, I see: 2015-04-13 12:13:05 DNS list lookup defer (probably timeout) for domain.tld.fresh.dieinafire.com: assumed not in list
A: Something is blocking you from running a DNS Lookup against the DNSBL *or* your DNS Queries are taking far too long to resolve. This could be a problem on your end *or* my DNSBL's end (one of the reasons I'm trying to load test it). Verify that you can query the DNSBL directly by running: dig +short test.fresh.dieinafire.com It should return '127.0.0.2' like below: # dig +short test.fresh.dieinafire.com 127.0.0.2
If it just returns to a blank prompt, then something is wrong and either your DNS resolvers in /etc/resolv.conf are causing problems or some firewall settings are at fault.
-
What is freezebloodsugarcure and where can I get it? Thanks! 0 -
This looks great BOates. I've had a ton of spam over the last few months and no matter how many filters a set in cpanel, it keeps coming. Looking at todays spam, it is in fact coming from a domain registered in the last day or 2, so I have installed this to give it a go. Just 1 question, I see it uses fresh.dieinafire.com, yours I assume, will emails automatically pass through if your server is down or unresponsive? Thanks for this. 0 -
Yep you're right. It works pretty close to SpamCop or SpamHaus do in terms of cPanel + Exim integration, just doing a lookup with a domain instead of an IP. If a lookup to the block list fails for any reason, the fallback behavior is to treat it like the block list responded that it's NOT spam. So if my server gets overloaded or for any reason it becomes unavailable, it would not negatively affect deliverability. 0 -
That's awesome. Thanks for this. I'll let you know how it goes. 0 -
You sir, are my hero! I woke up today to ZERO spam, whereas normally I have around 100 emails to delete. Thank you. 0 -
Fantastic! Yeah that's why I decided to share it in hopes others would experience that same spam drop off. It's instantaneous and super effective. Did you deploy it on a multiple servers or spread the word? Noticed today that my little VM that it's been running on on starting thrashing CPU handling the load and it looks like I'm getting tons of queries. I'm going to have to possibly look at expanding it/growing it (which is good!). Tried to spread the word on WHT some months back, but it would seem it is against their forum rules to essentially "advertise" a free service. 0 -
I've not spread the word. Only mentioned here. So no idea where the traffics come from. If the traffic becomes too much it would be great to get the server code to keep this running as it's the most effective spam protection I've had! 0 -
i really like the idea, but soon you will be out of resource, i hope the code don"t die. or at least you make a more preffesional DNSBL... and erase than annoyng cat from dieinafire.com xD good look ;) 0 -
Brilliant! Looking forward to trying it out! 0 -
It is incredibly effective. BOates to the rescue once more. :) 0 -
Thks a lot !! Works perfect ! I'm really happy with the result. Thks again 0 -
My bad, problem was something else. All working fine. 0 -
We have configured this dnsbl for our xwall gateway, and it actually caught some spam, but last couple of days it does not respond to ping. Is it still working? 0 -
I've noticed the odd bit of spam coming through, nowhere near as much as I used to get, so I was also wondering if it it maybe keeps going down. 0 -
Yes, last 1-2 weeks there has been large increase, and not detected by any blocklists. Wondering what's going on. 0 -
Nope it's still online and working. Looks like I recently messed up the record for 'fresh.dieinafire.com' specifically, but that does not affect the actual DNSBL functionality since Exim is only ever going to be looking up .fresh.dieinafire.com which has been functional. I've fixed the record now so that dig +short @104.236.11.151 test.fresh.dieinafire.com
As long as you get "127.0.0.2" back as a response, the service is online and responsive. If you are getting spam from newly registered domains from TLDs other than ".top"., post or message me a few of the example offending domains and I'll look into why they're being let through.0 -
Yes, I see it just started responding. 0 -
I just added this to one of my client's servers. Works great. I noticed that there are some timeouts in the logs, but nothing major. But it is blocking a ton of crap that was getting thru SpamAssassin. Thank you! Let us know how we can support your efforts. 0 -
I just added this to my server and it's working superbly! 0 -
Sounds like a great idea. But doesn't this mean you need to keep spamming the various whois servers, which might conceivably be against their TOS? Also, don't the whois servers eventually ratelimit or block you at your end? 0 -
A WHOIS only occurs once per domain (google.com had a lookup performed on it ONCE, every lookup after that is internally cached). A this point I have 1,812,859 cached domain lookups (Once whitelisted, I have no reason to ever lookup that domain again). At any given instant, there is about on average 2,500 "fresh domains" actively blacklisted (also cached). From there, there's other logic to prevent and ratelimit lookups for WHOIS lookups that fail (be it the domain is not registered or some actual failure) specifically to try and prevent abuse of a given TLD's whois service. Failed lookups simply return a negative response (not blacklisted) to the MTA to err on the side of allowing mail in. There's also logic to shift the blacklisted item into the whitelisted cache after its 5 day expiry time. Literally a registered domain is only ever looked up once. The amount of actual WHOIS lookups performed per-TLD per-day is actually fairly reasonable (so far). But you are correct, all it takes is a TLD organization to disagree and (either by request or by blocking) cause the lookups to cease for their TLD and render the DNSBL useless for their TLD. It's been operating since May or so without issue, but that's just anecdotal. The risk definitely is there. 0 -
Nice work BOates! I read through the thread and figured it was worth a shot. I put this on one of my smaller boxes that doesn't have a ton of mailboxes and within 10 minutes we caught the below domains. What's nice is based on the sender name before the new domain you can easily see that this is simply spam. - Removed - No Need For This Here - 0 -
A WHOIS only occurs once per domain (google.com had a lookup performed on it ONCE, every lookup after that is internally cached). A this point I have 1,812,859 cached domain lookups (Once whitelisted, I have no reason to ever lookup that domain again).
Thanks for the reply. One possibility I can think of is that a non-spamming, whitelisted domain could expire, and is then subsequently registered as a temporary throwaway by a spammer. To counter this would require at most one additional valid whois check per year per domain, but with millions of domains to recheck, it would quickly add up and possibly greatly increase the risk of being blocked.0 -
Yep, that's a loophole in my current method. However, at least at the moment, I have not seen this behavior and the added queries to check against this loophole would make the DNSBL more invasive to WHOIS servers like you say. One way I justified that it's not as important to re-check expired and re-registered domains is a similar reason why spammers seem to want "fresh" domains. All this spam that is being sent out is, eventually, over the course of a few days/a week, resulting in many URIBLS and other domain reputation based lists catching them. Even still whitelisted against my DNSBL, it would be more likely that some other block list WOULD have them blacklisted still. Similar to how people inherit IP reputation of the previous owner, I imagine/hope that the domains would retain their poor reputation and hopefully be considered useless to spammers. You are correct on the potential for legitimate/good reputation domains expiring and then being abused by spammers. At the outset, I think my response to that would be that attempting to be that "aggressive" in response with the added WHOIS queries needed would be beyond the scope of this DNSBL. Spamming WHOIS servers is not something I want to intentionally do. I could be wrong. But, you never know. If this DNSBL becomes reasonably popular, circumventing it may be eventually worth the effort. 0 -
Has anyone else using this started seeing a lot of spam in the last few days? 0 -
What's the creation date on the WHOIS data for the domains you're seeing get through, and what's the TLD in use -- are they all the same TLD? If you want to PM me the domains I'll check into it. 0 -
Just looking at the first spam that just came through, it's example.eu which was registered yesterday. 0 -
(Edit) That's why, the public WHOIS server for that registrar does not report any data over the normal WHOIS service. They redirect you to go to their proprietary web page and do a lookup there. My DNSBL requires that the creation date be viewable via the standard WHOIS service lookup. So any domains registered by that particular registrar are not able to be filtered by my DNSBL. Whois Record ( last updated on 2015-12-10 ) Domain: example.eu Registrant: NOT DISCLOSED! Visit - Removed - for webbased whois. Onsite(s): NOT DISCLOSED! Visit - Removed - for webbased whois. Registrar: Name: TLD Registrar Solutions Ltd Name servers: ns-usa.domain.com ns-canada.domain.com ns-uk.domain.com Please visit - Removed - for more info. 0 -
ok, that makes sense. Time to block all .eu email, I mean who uses that anyway ;) 0 -
I am testing this on 2 servers before making the change to all my servers I have. I will you all informed after a couple days of testing on how this goes. 0
Please sign in to leave a comment.
Comments
86 comments