-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Marc Perkel wrote:
> How do we isolate > end users so that they can't get viruses as easily and spread them as > easily? That would seem to be the job of filters, either upstream from the end-users or installed on their computers. Upstream solutions are usually preferable, if only because they tend to be more robust and maintained by people with more computer security knowledge and expertise, but obviously this can't be the entire solution. Upstream solutions work well for things like mail filtering, but less so for screening content being downloaded or uploaded via HTTP, FTP, IM, etc. That said, /containing/ infected hosts is probably an easier first step to achieve. Applying mail filtering to outbound as well as inbound mail would catch a lot of this (i.e. a "fence in" vs. "fence out" philosophy). ISPs also need to look at ways to auto-detect symptoms of "malware-like" activity--bursts of particularly-shaped traffic that can help them heuristically identify IP addresses on their networks that need to be isolated (or safely proxied). > I'm someone who works from home and > provides so service from home. So I would not want to be prohibited from > running an email server from home. Many broadband providers already offer a separate "business class" account for users who need static IP addresses, need higher bandwidth limits, rDNS entries, and want to host their own servers. Trying to do this sort of thing on a dynamic IP with some kind of dynamic DNS service is a kludgy solution that should be discouraged, provided that a "business class" alternative is available. By differentiating these types of broadband accounts, ISPs can use port-blocking more effectively. > All outgoing email from consumers should by default be required to use > authenticated SMTP or some new authenticated protocol. At least force > consumers to use the submission port and block off port 25 for outgoing > SMTP by default. If consumers were forced by default to send mail on a > different port then servers could determine if they were talking to a > consumer or if they were talking to another server. More specifically, it would allow your mail server to make stricter assumptions about what it receives on port 25. If it knows that all client-submitted mail arrives by other means, it can trust that whatever connections it receives on port 25 should be exclusively from other servers--hosts with MX records that can be verified. A connection attempt from a host without a MX record can be safely dropped in this case. In short, none of this advice is particularly new, and the archives of lists like SPAM-L will show that the anti-spam community has been clamoring for ISPs to adopt strategies like this for years now. In large part I think the reason for the slow adoption of these methods is inertia--larger networks run by larger companies need more hands and minds to maintain, much less modify, and so they go with "what works" until that ceases to be the case. When botnets become a large enough threat to their bottom line, they'll reexamine their priorities and we'll start to see action at long last. Unfortunately getting network admins to think in terms of "fencing in" rather than just "fencing out" involves something of a worldview-shift. Many of us are so busy worrying about blocking the bad stuff from /entering/ our networks that we don't think too hard about the fact that that stuff came /out/ of someone else's network. If we all did a competent job of watching our own networks to prevent our own users from harming networks outside our fences, the botnet problem would be all but dead overnight. Instead we spend most of our time worrying about putting up one-way walls to keep the invaders out, while our own users--often unknowingly--continue to spew outbound crud. - -- Robert LeBlanc <[EMAIL PROTECTED]> Renaissoft, Inc. Maia Mailguard <http://www.maiamailguard.com/> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFfalEGmqOER2NHewRAv03AKCEBAwGr/KLZ+Xq9dUnRKNJQu5UywCeMjut v7eWWNXrjppR95WHzS6ni2c= =0EjI -----END PGP SIGNATURE-----
