Yessir.
Limiting the number of logons over an interval would be good. So would
limiting the number of messages or recipients over an interval, as Matt
correctly pointed out.
Deriving passwords by brute force attempts has always been out there,
but an automated fashion for collecting the usernames and passwords is
new. I assumed the same thing that Sandy pointed out, which is that
SOBER is going after the low-hanging fruit, and presumably reads the
mail server name and port while it's collecting the username and
password. I would also assume that SOBER turns the mail server name
into a FQDN given the predilection for ISPs to call their mail hosts
"mail" or "smtp" or "pop" and provide the DNS search suffix in the DHCP
lease.
What I do find surprising is how few email packages aimed at ISPs
support the security features we've been talking about here to detect
the bad guys in house. Declude Hijack is a notable exception.
Corporations are in the same fix, as both are left with "roll your own"
solutions based on log file analysis.
What that means in the real world is that they govern by exception; they
don't have a security team at all, or they follow up on incidents that
are reported to them by an external body, e.g. "My users aren't getting
your mail anymore because your mail server is listed in SpamCop, CBL and
SORBS".
The spammers and malware writers will continue to find ways to use the
resources of other people. Once you've got a sensibly configured relay,
secure mailer scripts on your website, users with reasonably secure
passwords, SPF records, users using SMTP AUTH, you've taken the easy
stuff away from the bad guys.
But you still have to expect that they'll abuse something else, so you
still need to put in limits where you can, and monitor your logs for
abuse.
If you're interested, check out this paper from July 2004 entitled
"Stopping Spam by Extrusion Detection" from:
http://www.cl.cam.ac.uk/~rnc1/
And if you have any ideas or updated information, please share.
Andrew 8)
p.s. Sorry for the shot yesterday Matt, but when I see fish in a barrel,
I just can't help myself.
_____
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Darin Cox
Sent: Thursday, November 17, 2005 5:42 AM
To: [email protected]
Subject: Re: [Declude.JunkMail] OT: another SOBERing though
Another excellent point... limiting logon attempts.
This reminds me of a discussion a while back that also talked
about limiting POP3 connections from a single users to every x minutes
to reduce load.
Darin.
----- Original Message -----
From: Markus Gufler <mailto:[EMAIL PROTECTED]>
To: [email protected]
Sent: Thursday, November 17, 2005 2:34 AM
Subject: RE: [Declude.JunkMail] OT: another SOBERing though
As I can understand a feature like "max. logon try's between x
minutes" on the server would not prevent such hacking attempts because
they try to hack the login on a infected client.
Question: How will this work? Are passwords still so easy to
read as 10 years ago in Win95 or will the malware listen the IP-traffic
and read out the clear-text SMTP-Auth or POP3-Password?
Next Question: Does have someone here some or numerous cases
where a client behind your Declude-Wall has become a infected sender? In
my case here we have thousands of connecting clients but nearly none of
them are "in house" So I can't say it's not the case, but with my
current knowledge I know only a hand full of cases where a connecting
client was infected. Most of them because they are connecting also to
another unprotected Mailbox.
Markus
_____
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Darin Cox
Sent: Thursday, November 17, 2005 2:25 AM
To: [email protected]
Subject: Re: [Declude.JunkMail] OT: another SOBERing
though
So the upshot of this is we need to
1. Figure out a way to enforce strong passwords for mail
users
and
2. Monitor traffic for individual user accounts on an
intra-day basis, perhaps even have a means of detecting sharp increases
in traffic from a particular account and alerting an admin to
investigate. We do review a daily report the following morning of
traffic by domain, but don't have anything in place to monitor by
account, or to alert on an intra-day basis.
Something to look into...
Darin.
----- Original Message -----
From: Matt <mailto:[EMAIL PROTECTED]>
To: [email protected]
Sent: Wednesday, November 16, 2005 6:18 PM
Subject: Re: [Declude.JunkMail] OT: another SOBERing
though
Hmm, who would have thunk?
Subject: Re: [Declude.JunkMail] SPF Success
Date 12/24/2004 9:24 AM
http://www.mail-archive.com/[email protected]/msg22584.html
IMO, the best way to stop forging is to stop
zombie spammers. The way to do this is FIRST implement port 587 as
AUTH-only, and then widely block port 25. This means that mail clients
would exclusively use AUTH on private networks and connect to their mail
server on port 587 where only AUTHed connections would be allowed. Then
only servers would share non-AUTH E-mail on port 25. The only reason
why blocking port 25 is not very common currently is because it is
severely limiting to customers and would cause support issues for the
ISP. If you first did the migration to port 587 AUTH-only connections,
which would take several years to accomplish in good order, ISP's could
move forward with port 25 blocking and cause many fewer issues as far as
support and their clients were concerned.
Basically what I am saying is that forging isn't
the issue, it's spam zombies, and to go after it as a forging issue is
to miss the point. The big caveat here is that spammers will turn to
hacking AUTH in much larger numbers, and E-mail server software should
also widely implement a 'hijack' detection mechanism in order to help
stem the abuse. I have already noted much more hacking going on, first
with Earthlink's properties, and now with Prodigy as well. I have
little faith that these things will happen in the proper order or with
the expedience necessary unfortunately, especially because of what I
consider to be a distraction focused on forging coming from the likes of
SPF, Microsoft and Yahoo. I feel that the big players are missing the
point, and they are the ones that heavily influence E-mail client and
server software which is where the changes first need to be implemented.
Subject: Re: [Declude.JunkMail] Question on SPF
Setup. Was under You **May** etc **May** etc
Date 6/30/2004 12:33 PM
http://www.mail-archive.com/[email protected]/msg19684.html
What I do think would work much better in the
near term would be for every mail server to support and require SMTP
AUTH through port 587 as proposed, and then have every ISP out there
block port 25 which would be used exclusively for non-AUTH'ed E-mail
between systems. That would cut the zombie problem down dramatically
without interrupting service, but this will probably take 5 years or
more to widely implement. I think this would have a much larger effect
than SPF in terms of blocking forging E-mail, the majority of which
comes from PC's attached to these residential ISP's presently. AUTH
hacking, or even server hacking however will become much more
predominant when the bar is raised in this manner, but there should be
many fewer machines to track.
While this is certainly a bit of me patting myself on my
back, it is also a reminder to all that the worst is yet to come and for
the most part people are totally unprepared for this sort of thing. So
what's next? Maybe Geocities spam sent through hacked Yahoo accounts???
Oh wait, that's already happening.
Matt
Colbeck, Andrew wrote:
So, we've seen the recent SOBER variants used
their own SMTP engine to
propagate as well as a predefined list of
usernames and passwords at
ISPs to send themselves.
We've also seen that keeping viruses and spam
out of our mailboxes is
easier when we can identify the sender as a
zombie, and that it is
harder when the junk is coming from a valid ISP
and/or user at an ISP.
http://www.viruslist.com/en/weblog?done=vlpolls_resp155596558
Well, Kaspersky is reporting that the latest
SOBER is also stealing (at
least) Outlook usernames and passwords from
infectees.
Therefore, we can reasonably expect more junk
coming from AUTH'ed
senders.
Andrew.
---
This E-mail came from the Declude.JunkMail
mailing list. To
unsubscribe, just send an E-mail to
[EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail". The
archives can be found
at http://www.mail-archive.com.
