Larry Seltzer wrote:
Trojaned machines - by their nature authenticated
No, not actually. The authentication process is SMTP server to server, so
unless the
trojaned system has access to an open relay which is, nevertheless, properly
accounted
for in the SPF/Caller ID DNS entries, the trojan will need to have proper SMTP
AUTH
credentials to some server. They don't currently work this way, and it seems
unlikely
that an administrator would leave relays open but implement domain-level SMTP
authentication.
One of the big ISPs I spoke to claims that 80% over their incoming
traffic is coming from other ISPs' MTAs, which are used by trojaned
machines to send mail, NOT by trojaned machines sending mail directly.
No SMTP AUTH is used - the mail is send directly to the ISP's MTA and
the ISP trusts the incoming connection because they know they our IPs.
The question is why aren't they doing rate limiting, and I will get to that.
But you should step back for a second. There is a basic principle in
security - if you have physical access to the machine, then you cannot
secure it. Unless the user is running some old copy of MS-DOS or Linux
under a restricted access account, chances are he will be running
Windows with administrative access and Outlook or Outlook Express.
Nothing against Microsoft, but statistically most desktops in the world
run Windows. Chances are that the use is stupid enough to click on the
MyDoom virus in his inbox. At this point the virus has full
administrative access to his machine. If the virus writer is smart
enough, he might even make it a root kit, so the virus will have full
access to all layers of the operating system.
Now the user will be using some form of authentication method be it
SMTP AUTH with passwords, Verisign's or RSA's hardware tokens, smart
cards, etc. Now we assume that the user does not have to do the
authentication process every time he does his email, but rather his
client or OS caches the password. The virus having full control of the
machine, can very easily "piggy back" on that authentication process and
send spam via the user's regular account.
LMAP proposals do stop trojaned machines from sending email to other
machines and claiming to be from someone else's domain. That's all they
do - they do not stop spammers from using their own domains, or relaying
via user's credentials. Granted this narrows down the playing field, but
we still need to look at ways to be able to detect a malicious machine
relaying email via a throwaway domain or via the user's own account. At
this point all of the LMAP proposals are going to be discussed at the
BoF, and if the IETF creates a WG for them after this week's meeting,
than it will be out of scope for the ASRG.
Now going back, how do you detect malicious machines relaying mail for
throwaway domains or via the user's account. One way is via MTA MARK
which does cause problems for users who want to run their own MTAs. But
the argument is - if you want to run your own MTA, you must take
responsibility for it. Another way is via reputation/accrediation
schemes, but it remains to be seen if they will be administrated
properly and fair unlike many of today's blacklists.
However, we must not lose the sight of the fact that the one known fact
about spam coming from the hijacked machine is the IP. The network
hosting the IP should also be responsible for implementing some kind of
scheme to deal with trojaned machines. One way to approach this issue is
to detect large spikes in email traffic and queue the mail temporarily
alerting the user. In regards to this specific method, we are currently
looking for volunteers to write a BCP on this and other methods of
dealing with hijacked machines from the originating network's point of
view.
Yakov
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg