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:
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.
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 -----
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
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 -----
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.
