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

[Rich Kulawiec]

On Thu, Jun 05, 2008 at 08:32:19AM -0400, Phil Stracchino wrote:
> Everyone's probably seen the report by now, citing that in these three
> worst TLDs, as many as one site in ten carries a payload of malware.
> So, since the kids aren't good at paying attention to such things, I
> decided in the interest of safety to block all traffic to and from those
> TLDs at the firewall.

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

2. Consider blocking:

	.ru - huge spam problem, refuses to take any action
	.tr - growing spam problem, refuses to take any action

3. Subject mail to extra scrutiny:

	.ae .af .ar .bd .br .bg .cc
	.cl .co .cy .do .gr .id .in
	.iq .ir .jp .kh .kp .lb .ly
	.my .mx .ng .pe .ph .pk .pl
	.ro .sa .sg .sy .th .tk .to
	.tv .tw .ua .vn .ye


As I said, these are *baseline* suggestions which will need to be
modified to suit each particular environment.  For example, universities
in North America probably can't block .cn outright.  As with any
anti-spam measure, log analysis is required to assess the impact of
a proposed change, and in-depth knowledge of local traffic patterns
will help in that assessment.

Locally, TLD-based blocking nails about 30% of incoming spam at the
moment with a false positive rate below 1e-6.  (Both rates vary with
changes in incoming spam mix and with where in the chain of checks this
particular one is applied.)

> 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)

You'll want these:

	http://www.okean.com/koreacidr.txt (currently 406 entries)
	http://www.okean.com/chinacidr.txt (currently 694 entries)

There's also:

	http://www.blackholes.us/zones/countries/countries.rbl  (approx 41K entries)

which I don't believe is currently maintained, but at least covers
some of the network space.

And you might want to take a good look at:

	http://www.effierover.com/downloads/scorched.earth.txt  (approx 8K entries)


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.

You can do the same with any entries from countries.rbl if you wish,
but unless that data starts being updated again, I'd be cautious with
its use.

The scorched earth list (maintained by long-time anti-spammer Loy Ellen
Gross) can be used en masse or you can select entries from it via awk
or sed or perl or whatever.  The format is pretty obvious if you page
through it -- it's not hard to judiciously pluck out entries whose inclusion
will yield high true positive and low false negative rates.  If you're
doing scoring (as opposed to outright blocking) then tiered approaches
are possible, i.e. "block those, score these higher".

However you use any of these, I recommend (a) clearly tagging the entries
generated in your logs so that you can tell which caused what (b) phasing
them in one at a time so that you can assess impact and (c) thinking
through which will block the most with least resources and putting
those first.  (For example: the DROP list should be first in almost
everyone's setup because its use does not require any rDNS lookup and
it intercepts traffic before it reaches any local hosts.  Another example:
if you decide to block China outright in your MTA, then put the list of
network blocks via Okean ahead of the check for the .cn TLD, again,
because it avoids an rDNS lookup.)

---Rsk