Chris-Linfoot.net

From this blog:
Domino server; local blocking by IP range (CIDR blocks)

From LDD:
Spam blocking without DNSBLs

These both rely on that single server configuration field to the right here. Looks innocent enough, but used well it is immensely powerful so don't overlook it.

While the addition of support for DNSBLs in Domino 6 is more than welcome, it is far from a panacea. I have seen many comments from disappointed Domino administrators to the effect that they have enabled DNSBL blocking or tagging and selected one or two lists to query - yet still the spam gets through.

To understand why this is and what we can do about it, we need to understand the modus operandi of spammers and to revise this understanding continually as their methods change . We must adapt to the changing wiles of the spammer or drown in a deluge of spam. This is the most basic evolutionary choice; change or die!

For now, a very good place to start would be LURHQ Threat Intelligence Group's write up on Sobig.A.

DNSBLs rely on predictability. That is, if spam has come from this IP in the past, it will do in the future, so if I list this IP in a DNSBL future spam will be defeated. This approach (piecemeal; one IP at a time) has worked effectively against open relays and spamhausen (indeed still does). But open relays are not the problem they once were...

A very high proportion of spam is now routed via proxy servers and most of those proxy servers are only proxy servers at all because they have been victims of hacks like Sobig (the A and the E variants of this worm were the most effective so far, but we have not seen the last of it). Combine this with the proliferation of broadband services and the result is that it is increasingly difficult to predict where spam will come from. Thus it is increasingly common to receive spam, look up the IP address of the sending host and find that it has been listed in Spamcop or DSBL some time after you received the spam. This similarity between spam and viruses is not coincidental and our approach to the prevention of both is beginning to converge (qv pre-emptive blocking).

This is where local blocking comes into its own.

NB: None of what follows is any way a criticisim of NAC; they are simply a typical ISP with many users, some of whom have fallen victim to trojans and similar hacks. This makes them like most other ISPs in the world; they are not the bad guys. Those responsible for Sobig and similar worms are the bad guys. Now that I have made this clear, on with the detail...

What you need:

• Lots of spam (set up some traps - I may blog about that in future...)
  
• Sam Spade for Windows
  
• A Domino 5 or 6+ server as MX for your domains
  
• Patience/perseverance

Let me illustrate with an example:

Received: from s199.dial3.sne.nac.net ([64.21.105.199])
by your.domino.server (Lotus Domino Release 6.0.1CF1)
with SMTP id 2003092719124942-173 ;
Sat, 27 Sep 2003 19:12:49 +0100
Received: from bugs.debian.orgs [1.222.119.110]
by s199.dial3.sne.nac.net (Postfix)
with ESMTP id E0DDFD709F05
for <victim@your.domain>;
Sun, 28 Sep 2003 06:17:37 +0000
Date: Sun, 28 Sep 2003 06:17:37 +0000
From: Sandy <sandyhothotndsf@yahoo.com>
Subject: Somebody has sent you a message... shgjetf hdy
To: victim <victim@your.domain>
References: <78A54B1DB7551EF0@your.domain>
In-Reply-To: <78A54B1DB7551EF0@your.domain>
Message-ID: <0D0DAFA204109920@yahoo.com>

Above is a set of headers from a recent spam. The sending host is almost certainly an open proxy and the second received header is forged.

Most DNSBLs would list 64.21.105.199 and leave it at that. What you do is plug the address into Sam Spade and use the whois tool:

10/02/03 11:29:49 whois 64.21.105.199@whois.arin.net

whois -h whois.arin.net 64.21.105.199 ...

OrgName: Net Access Corporation
OrgID: NAC
Address: 1719 STE RT 10E
Address: Suite 111
City: Parsippany
StateProv: NJ
PostalCode: 07054
Country: US

NetRange: 64.21.0.0 - 64.21.191.255
CIDR: 64.21.0.0/17, 64.21.128.0/18
NetName: NAC-NETBLK03
NetHandle: NET-64-21-0-0-1
Parent: NET-64-0-0-0-0
NetType: Direct Allocation
NameServer: NS1.NAC.NET
NameServer: NS2.NAC.NET
Comment: ADDRESSES WITHIN THIS BLOCK ARE NON-PORTABLE
Comment:
Comment: * Reassignment information for this network is available
Comment: * available at whois.nac.net 43
RegDate: 1999-12-22
Updated: 2001-08-22

... and so on...

This is Net Access Corporation, an ISP whose coverage area spans from Massachusetts to Washington DC with a core market focus in the NY/NJ region. Like many larger ISPs, NAC operates a whois server which will give further detail on how addresses within their CIDR blocks are reassigned. In this case, the whois server is at whois.nac.net...

So, following up that reassignment information...

10/02/03 11:30:19 whois 64.21.105.199@whois.nac.net

whois -h whois.nac.net 64.21.105.199 ...
NAC-Rwhoisd32 Server Ready - [hydrogen/43] Rwhoisd32 v1.0.55

Net Access Corp. (NETBLK-NET-40156900-24)
PO Box 55
Denville, NJ 07834
OrgID : NAC-25
Netname : NET-40156900-24
Netblock: 64.21.105.0/24
NetUse : dial3.sne

... and so on...

It is helpful to see whether the abused IP has DNS, so use the dig tool...

10/02/03 11:29:54 dig 64.21.105.199 @ your.name.server
Dig 199.105.21.64.in-addr.arpa@your.name.server ...
Non-authoritative answer
Recursive queries supported by this server
Query for 199.105.21.64.in-addr.arpa type=255 class=1
199.105.21.64.in-addr.arpa PTR (Pointer) s199.dial3.sne.nac.net
105.21.64.in-addr.arpa NS (Nameserver) ns1.nac.net

Note that the resolved name contains the word "dial" and that the whois info at whois.nac.net confirms this in the field "NetUse". NAC's acceptable use policy says, among other things:

E. SYSTEM RESOURCES

5. Subscribers may not run programs which provide network services from their accounts. Example of prohibited programs include, but are not limited to, mail [my emphasis], http and irc servers, and multi-user interactive forums.

So, we have an obvious dial pool here which should never be used to send direct to MX and is thus very safe to block completely. You now have a choice - list [64.21.105.*] or dial3.sne.nac.net in "Deny connections from the following SMTP internet hostnames/IP addresses:"

The bad news is, you have to do this a lot of times. The good news is that within a month or two, if you are diligent, you will have created a permanent barrier against far more abusive messages than would be possible with DNSBLs alone.

As of now, we have a total of 973 items blocked here, of which 380 are ranges of IP addresses ranging from /32 (single IPs) up to a few /14 networks, and the balance are sub-domains of ISPs providing DHCP/DSL/dial-up service.

A side benefit of this, beside the extra level of spam blocking not provided by DNSBLs alone, is that if you are using DNSBLs to block or tag, hosts matched by your local blocks are not looked up in DNSBLs (no need to do this as you have explicitly said you don't want their mail). In our case this saves c. 20% of all DNSBL look-up overhead.

Category: Domino: Administration
Technorati: Domino: Administration

1. Declan Lynch03/10/2003 15:18:53
Homepage: http://www.qtzar.com

Can we all get a copy of your block list to save us a lot of time building up our own ?

2. Chris Linfoot04/10/2003 10:48:53

Legally somewhat shaky I regret to say - depends on whether you buy the usual DNSBL defense that this is not an opinion, just a list of addresses. But in my case, there is a pretty substantial documentary audit trail that says it is my opinion.

I may be able to give some hints though... Let me think about that.

cwl

3. Chris Linfoot07/10/2003 15:01:00

See today's blog. Have published (perhaps temporarily) a partial list.

cwl

4. Stew-ma-roo08/10/2003 19:11:15

Looking through your list...(from a North-American's perspective) I noticed that you have precious few **.rr.com (where the ** represent various US regions). I don't know how sharp the Warner Bros. boys are with their mail systems, but I have found most (if not all) .rr.com folks being wide open relays/proxies...I would have figured a much larger presence in the list. Although, being on the other side of the pond, I suppose I would get hit from them more often than yourself?

Just a quaint observation though...maybe geography is not as much of an issue in this case. An interesting study I suppose, in another calling.

5. Chris Linfoot08/10/2003 21:24:03

No, we have a much larger number of *.rr.com entries in our list than just those published here.

The list I have published is perhaps 1/3 of the whole list. I have deliberately held back entries for two reasons:

- many entries on our private list are spammers (the bad guys) - I am not naming them publicly because I don't want to get sued and in any case, sbl.spamhaus.org is your friend

- the balance are dialup/dynamic entries where I do not have direct evidence of abuse (i.e. spam in hand) to support the listing

I chose when publishing the list to select only dynamically assigned pools where I have in my posession samples of spam sent to accounts here which support the listings.

Hope that makes sense.

6. Stoomaroo09/10/2003 21:12:47

Crystal clear. I floated the idea to my Corporate Security advisor -- "We do not have any business in say, China. The company does not intend to ever pursue Chinese business, or outsource its operations there. Why not just block all traffic from Chinese ISP/NSPs? What business impact will it have on the company -- besides cutting out some of our SPAM?"

Perhaps a little narrow-minded solution in terms of the "global economy" view that many propose...however, it got a couple of management people scratching heads...

Unable to post a comment? Please read this for a possible explanation...