[Asrg] Re: Asrg Digest, DNSBL BCP v.2.0

gep2 at terabites.com gep2 at terabites.com
Sat Mar 3 02:59:00 EST 2007


On Fri, 02 Mar 2007 23:19:03 -0500
  Stephanie Erin Daugherty <stephanie at ahbl.org> wrote:
> Ok... I'm putting on my Nomex suit for this reply.
> 
> Posted and mailed:
> 
> gep2 at terabites.com wrote:
>>
>> Worse, from a Internet strategic standpoint, the dangers 
>>of this kind 
>> of blunt-instrument blocking of E-mails for AN ENTIRE 
>>COMPANY just 
>> because ANY ONE computer within their network is 
>>infected (and it 
>> could even be an infected notebook computer carried in 
>>from home and 
>> connecting to the office wireless LAN) will force more 
>>companies to 
>> insist on MORE DANGEROUS separate, routable IP addresses 
>>for each 
>> machine in their company.... so that blocking will 
>>affect JUST ONE of 
>> their machines and not put the whole company out of 
>>business.  
>> Ultimately, this "solution" just puts dramatically more 
>>(and very 
>> unwanted) pressure on the limited IP address space, and 
>>INCREASES the 
>> likelihood of getting the company's machines infected 
>>since now their 
>> machines each have a real, routable IP address that can 
>>be attacked by 
>> scanners and other exploits originating from outside the 
>>company.
>>
> Routeable addresses are not inherently less secure. NAT 
>is not the only way, or even a good way to secure hosts. 

Securing the hosts is not the issue here.  Nor, in fact, 
securing clients!  The fact is however that typical user 
desktop machines are SAFER if just anyone anywhere on the 
Internet can't reach out and poke them directly.

>It may work for that in some situations, but it's less 
>that optimal, and was never intended to provide security. 
>(and in fact, there are countless tricks to break through 
>NAT anyway these days).

Again, client security isn't really the issue, although 
that IS a benefit, FWIW, of NAT.

> NAT was created to deal with a perceived shortage in 
>IPv4 addresses. It's not a magic bullet, and in fact, 
>it's actually harmful in many ways:
> http://www.cs.utk.edu/~moore/what-nats-break.html
> http://www.faqs.org/rfcs/rfc1627.html
> 
> If you choose to present your entire network to the 
>world as being a single machine, then, it and any abuse 
>from it will be treated as such, that's just a chance you 
>take. In this respect NAT is actually more dangerous, as 
>the ability to account for what's happening stops at your 
>network's border, 

Exactly.  And THAT is a HUGE issue.

>and NAT is often substituted for proper 
>security and network design - which includes use of 
>application layer firewalls, intrusion detection, and 
>application proxies to create and enforce a strong 
>security policy.

That's fine for companies like General Motors or Ebay or 
Amazon.  What you're suggesting is arguably inappropriate 
for a 15-person company with NO inhouse IT staff at all 
(say, a doctor's office).  We're talking about a company 
here that uses ONE single Novell server running the whole 
company.

> Put your servers in a real DMZ, with real IPs, and a 
>properly constructed firewall. Consider putting your 
>users behind proxy servers instead of or in addition to 
>NAT, so that they have exactly the access they require, 
>no more, no less. Machines that don't send mail directly 
>out to the internet shouldn't have the ability to do so. 
>This is common sense.

Ironically, the solution we (at least initially) had to go 
to involved us moving AWAY from our inhouse outgoing MTAs, 
and having to ENABLE the applications at individual user 
desktops to route their e-mails directly to out-of-house 
servers.  This is neither safer, but also is MUCH slower 
as viewed by the users than allowing their inhouse mail 
servers to buffer such operations.

> Intrusion detection would have let you catch this 
>earlier, probably before you were listed on DNSBLs.

Again, it's miraculous we caught it as fast as we did, 
given that the company in question really has no inhouse 
IT staff.  I provide their system support, remotely from 
halfway across the country.

Note that the blacklisting taking effect at E-fax, 
specifically (and which suddenly prevented the company 
from sending out more than 500 faxes a day) happened at 
least three days after (TTBOMK) the infection HAD been 
cleared up.  (Of course, who can be sure?  The 
blacklisting company doesn't tell us EXACTLY what they 
were blacklisting us for).

>> So, again, I will EMPHASIZE that the question should NOT 
>>revolve 
>> around the finer points of how to implement 
>>IP-address-based 
>> blacklists, who should maintain them, how to distribute 
>>them, how to 
>> phase them out eventually, and such CRAP!!  We are 
>>arguing the finer 
>> points about what is INHERENTLY a VERY flawed approach, 
>>rotten to its 
>> very core AS A CONCEPT, where what we OUGHT to be doing 
>>instead is to 
>> figure out better and more effective ways to efficiently 
>>and 
>> accurately DIFFERENTIATE good mail from bad.
>>
> There are also ethical implications which would suggest 
>that any content-based approach is just as flawed, 
>because it creates an infrastructure for censorship just 
>as easily as it creates an infrastructure for stopping 
>spam.

That would be true if the "censorship" were imposed by an 
ISP or some centralized authority.  It's far less of an 
issue if the routing and acceptance criteria is controlled 
by THE RECIPIENT THEMSELVES, who have the ABSOLUTE right 
to determine what does and doesn't go into their inbox, or 
(at a minimum) what they do (routing, reading, discarding 
read-or-unread, etc) regarding the incoming messages they 
receive.

>> As I have pointed out, such an approach would (in the 
>>example I gave) 
>> efficiently perform such triage on the messages coming 
>>from dear old 
>> Aunt Gertie's machine, allowing her legitimate mail to 
>>continue to be 
>> delivered while effectively guaranteeing that the 
>>spambot-generated 
>> garbage running on her same machine and transiting the 
>>same server(s) 
>> would be T-canned and never seen by a human (and 
>>therefore, hopefully, 
>> not be worth injecting into the Net in the first place).
>>
> If dear old aunt gertie is leaving her machine on the 
>internet after it's been compromised by a virus, she 
>either doesn't care, or doesn't know better, and in 
>either case, is doing harm to others by her refusal or 
>inability to deal with the problem, so she's arguably 
>just as big of a problem as the virus itself.

The point is that SHE PROBABLY DOESN'T KNOW.  And probably 
wouldn't understand what it all meant, even if told.

I'm not suggesting that we ought to leave infected spambot 
zombie armies operating freely all over the net.  Indeed, 
my proposals are intended to virtually eliminate (at 
least) E-mail as a (direct) recruitment vector for that. 
 But if you shut down a user because they had been 
infected, eventually you'll shut down nearly everybody.

>> Key to this triage, I believe is:
>>
>>    1) denying spammers and abusers (in a robust way!) 
>>the ability to 
>> conceal or obfuscate malicious or spam content by ruses 
>>based on HTML, 
>> text-as-image, scripting and the like;
>>
>>    2) forcing at least initial-contact e-mails (those by 
>>which a 
>> sender establishes a trust relationship with the 
>>intended recipient) 
>> be sent in plain text so that they can be analyzed 
>>effectively by a 
>> SpamAssassin-style analysis program;
>>
>>    3) allowing a recipient to control just exactly what 
>>sort of more 
>> advanced content they are ready and willing to accept 
>>from each 
>> specific sender, and (ideally) how they wish to 
>>additionally establish 
>> the legitimacy of that sender's messages.  (Prearranged 
>>masthead on a 
>> newsletter, personal SIG file for mail from an 
>>individual, 
>> characteristic keywords in the message or subject line, 
>>etc etc).

> These would help, but they are not enough - 

I agree.  Content analysis is key, too.  But without in 
the first stage denying the spammers the use of evasion 
techniques based on text-as-image, scripting (decryption 
etc), HTML, linked images, attachments, and so forth, 
content analysis can NEVER be nearly as effective as it 
can be otherwise.

>and without 
>extensive cooperation will never be effective. 

Agreed that spammers KNOWING that their spam has a 
negligible chance of being delivered and read will make 
them less likely to still try to send it.  But meanwhile, 
even just a SINGLE recipient no longer feeling plagued by 
spam and worms is probably worthwhile, at least as 
experienced by THAT user.

> I want to 
>see better solutions, but barring making some solutions 
>mandatory (and I shudder to think of how you could do 
>that without gov't involvement, which will never happen 
>on a global level anyway), you aren't going to do enough 
>from a content standpoint.

I think you can do FAR BETTER from a content standpoint 
(content analysis, such as Spam Assassin, following "a 
priori" blocking of mail from unknown/untrusted senders 
containing HTML or attachments) than you can using any 
kind of IP-based blacklisting or other "reputation" 
scheme.

>> Here on this list, we keep falling back into this nasty 
>>business of 
>> arguing about how an INHERENTLY FLAWED scheme (and I'm 
>>talking about 
>> IP-address-based blacklisting) should be done, rather 
>>than recognizing 
>> ONCE AND FOR ALL that it is simply a ROTTEN IDEA FROM 
>>THE BEGINNING 
>> and that we OUGHT to be working on finding a BETTER 
>>solution which is 
>> better long term both from the standpoint of CONTROLLING 
>>spam, of 
>> encouraging (in a practical way) responsible computing, 
>>and which 
>> isn't just encouraging these costly, ineffective, and 
>>ultimately 
>> COUNTERPRODUCTIVE games of after-the-fact 
>>"whack-a-mole".
>>
> I'll agree that its a horrible idea. 

I'm glad we at least agree on THAT point.

>At one point, a 
>DNSBL could effectively stop a lot of spam. Now, most 
>DNSBL operators and DNSBL users have realized that the 
>technology long ago ceased to be useful in stopping all 
>but the most persistent and long-lived spam sources, and 
>compromised hosts.

And, the other point is that you have FAR too much 
collateral damage.

> So, you might ask, what are DNSBL's still useful for? 
>Mainly, four things:
> * Keeping track of compromised hosts, because they 
>present a threat to the internet as a whole.

"Keeping track of" is probably less of interest to anybody 
as a third party than it would be to establish a mechanism 
for robustly alerting someone technically responsible at a 
given sender... IF one could reliably establish WHO the 
actual infected computer or other spammer really was.  It 
would be nice, for example, if one could REALLY notify 
(say) Gertie's ISP so that they could (in theory, anyhow) 
try to contact her to let her know about the problem.

> * Keeping track of hosts that shouldn't be sending mail 
>- machines on networks where servers aren't allowed for 
>instance.

Personally, I think that is still a violation of "net 
neutrality".  While I accept that kind of crap (for 
example, arbitrary restrictions that people have to pay 
dramatically more for a "business account" for their home 
offices since "residential accounts" 'are not allowed to 
run servers') I think that the Net as a whole would be a 
far, far better place if individual users COULD have their 
own Web servers online, rather than having to pay premium 
prices to third-party Web hosting companies.  I would far 
rather have, for example, a Web-based subdirectory on my 
local hard drive where I could place documents (contracts, 
photos, other files) where other authorized users could 
just come by and get them at their convenience.  (For 
example, some years ago I helped a guy who was writing a 
thesis about the early days of the microprocessor and 
personal computing, and I've got a copy of his paper 
online through my personal Web site... which probably 
doesn't get accessed five times a year, and is painfully 
big to store in my ISP-provided "personal Web space".... 
but OUGHT to be available online SOMEWHERE, and certainly 
don't mind having it occupying disk space on my home LAN 
here.)

> * Brute-force education of end users and server 
>administrators about community standards of security and 
>acceptable behavior on the internet.

That's fine for the users technically savvy enough to 
understand that.  Aunt Gertrude is barely able to power up 
her machine and enter an E-mail message.  And there are 
tens of millions of users just like that, Net-wide.

> * Bringing the problems that allow spam and other 
>network abuse to the wallets of those who can do 
>something about it.

Worse, also to those who CANNOT.  :-(

> It's that last one that's the big one.
> 
> Unfortunately, there are some providers who wouldn't 
>kick spammers off their network, if not for the fact that 
>DNSBLs would soon force them out of business.
> DNSBLs are unfortunately very good at this one thing - 
>making "not my problem" a big enough issue that ignoring 
>security, permitting abusive behavior, or ignoring the 
>basic principles of the internet becomes costly enough to 
>become a problem worth fixing.

Agreed that it gets people's attention.  (So would setting 
fire to their building, though).  I'm not convinced that 
it is an appropriately measured, limited response.

> As a DNSBL operator, I don't like this aspect of it, but 
>it's the same principle as behind things like the 
>infamous UDP (http://www.stopspam.org/faqs/udp.html). 
>Ultimately, a DNSBL does not stop spam. A DNSBL brings 
>the problem to the wallet of someone who can, by 
>providing mail admins that care about the problem the 
>tools to block mail from those that don't care, or are 
>contributing to the problem through ignorance or malice.

True, but (again) at what I consider to be an unacceptably 
high cost, compared to less abusive methods.

>> We OUGHT to be working on preventing spam (and viruses) 
>>from getting 
>> delivered THE FIRST TIME, rather than worrying about 
>>locking the barn 
>> door after the horse has already gotten out...!
>>
>> Dammit, people, we keep going back to what color fabric 
>>we're going to 
>> use to upholster the "whack-a-mole" mallet, rather than 
>>coming up with 
>> a real SOLUTION for this problem...!!!  :-((
>>
> I'm open to solutions, but just because the one's we 
>have suck, we shouldn't abandon them until such time that 
>we do have something better, and have it working. Spam is 
>ultimately both a security problem and a financial 
>problem though.

Well, I've posted here repeatedly what *I* think is a 
major step forward towards an INTELLIGENT solution for the 
problem... selectively blocking HTML and attachments via a 
fine-grained whitelist, on a sender-by-sender basis as set 
by each recipient, as a first-step prior to passing 
incoming E-mails through a content analysis system.
  
> Solutions have to come from all levels, and at the most 
>basic level, the critical work is in detecting and 
>preventing intrusions so that abuse can only come 
>directly from the abusers themselves.

Eliminating the practicality of delivering viruses and 
worms by E-mail is a major step in the direction of 
reducing the ability of spammers to recruit spambot zombie 
armies.

> -Stephanie

Gordon Peterson
http://personal.terabites.com
1977-2007  Thirty year anniversary of local area 
networking



More information about the Asrg mailing list