[geeks] .hk, .cn, .info considered harmful

[Phil Stracchino]

Rich Kulawiec wrote:
> Yep.  I also -- unless you have a business/personal need to receive
> mail from it -- recommend blocking .kr outright.
> 
> This isn't anything particularly new: those of us who work in the
> anti-spam area have been aware of it for a long time.  Locally, I've
> had the entire .info TLD blocked outright for years, and blocked the idiotic
> and completely useless .mobi TLD the day it went live.  One of the dirty
> little secrets of the registrar business is that they support these TLDs
> (a) because it gives them the opportunity to sell thousands of new domains
> to those engaged in spam/spyware/etc. and (b) because it in some cases
> forces the hands of those with domain names in other TLDs, who may feel
> compelled to pre-empt abuser co-option of their domain names by buying
> them first.  Thus we have debacles like .info and .mobi and which there
> was and is absolutely no need for.
> 
> Thus my baseline suggestions are:
> 
> 1. Block outright
> 
> 	.cm - sold out entire TLD to typosquatter
> 	.cn - enthusiastic spam support
> 	.hk - enthusiastic spam support
> 	.kr - spam support plus enormous number of hijacked systems
> 	.ws - run by spammers
> 	.mobi - pointless, useless TLD used only by incompetent morons
> 		who don't know what subomdains are for
> 	.info - overrun by spammers
> 	.biz - overrun by spammers -- so heavily blocked net-wide that even
> 		they are abandoning it
> 	.name - refuses to operate proper WHOIS service, therefore cannot
> 		be considered legitimate TLD


Where mail is concerned, yeah, I've been blocking .kr and .cn for years.
 I have literally never received a single piece of mail from a .kr
domain that was not spam.  Can't say I've ever seen anything from .mobi,
but I think dspam is already catching everything that comes in from
.biz.  I appreciate the tip about .cm and .ws TLDs.


>> Problem:  What netblocks to actually block.  I managed to find one site
>> offering a list of .cn and .hk netblocks; the combined total is over
>> 10k, gzipped.  There's got to be a better solution than that.
> 
> You want this:
> 
> 	http://www.spamhaus.org/DROP    (currently 125 entries)

This, I can use.

> You'll want these:
> 
> 	http://www.okean.com/koreacidr.txt (currently 406 entries)
> 	http://www.okean.com/chinacidr.txt (currently 694 entries)

These are both 403.

> There's also:
> 
> 	http://www.blackholes.us/zones/countries/countries.rbl  (approx 41K entries)

Yup, I've been using those for a long time.


> Now let me 'splain.  First, you want to use the DROP list in perimeter
> devices to bidirectionally block all traffic from listed blocks.  Update
> it once a month.  The DROP list carries networks that are either (a) hijacked
> or (b) 100% spammer-controlled or (c) both.  There is no reason for any
> production network to accept traffic from or send traffic to these.
> (Spamhaus coordinates with ARIN to ensure that any reclaimed blocks are
> off the DROP list for a while before being re-issued.)
> 
> The Okean blocks are updated frequently; I refresh my local copies about
> once a week.  You can use these in perimeter devices or in your MTA.
> How to use them in your MTA obviously depends on what you're running;
> if it's sendmail, you'll need to push them through cidrexpand before
> dropping them into the "access" file, as sendmail does not understand
> CIDR notation and works solely off A/B/C blocks for performance reasons.

I'm really not that concerned about mail here.  I have mail spam under
control.  I'm not looking for a spam-blocking solution; I have one.  I'm
looking for a simple way to drop all traffic from these TLDs at the
firewall.

So far, I don't have a better solution than to maintain a text list of
the bad netblocks, add an empty persistent table to pf, and write a
script that loads the table from the list.



-- 
  Phil Stracchino, CDK#2     DoD#299792458     ICBM: 43.5607, -71.355
  alaric at caerllewys.net   alaric at metrocast.net   phil at co.ordinate.org
         Renaissance Man, Unix ronin, Perl hacker, Free Stater
                 It's not the years, it's the mileage.