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

Ok... I'm putting on my Nomex suit for this reply.

Posted and mailed:

gep2(_at_)terabites(_dot_)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. 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).
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, 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.
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.
Intrusion detection would have let you catch this earlier, probably 
before you were listed on DNSBLs.
> 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.
> 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.
> 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 - and without extensive 
cooperation will never be effective. 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.
> 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. 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.
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 hosts that shouldn't be sending mail - machines on 
networks where servers aren't allowed for instance.
* Brute-force education of end users and server administrators about 
community standards of security and acceptable behavior on the internet.
* Bringing the problems that allow spam and other network abuse to the 
wallets of those who can do something about it.
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.
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.
> 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.
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.
-Stephanie


_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg