Re: [Asrg] Re: Asrg Digest, DNSBL BCP v.2.0
2007-03-04 23:00:02
On Sun, 4 Mar 2007 15:17:55 -0500
Matt Sergeant <msergeant(_at_)messagelabs(_dot_)com> wrote:
On 4-Mar-07, at 2:18 PM, <gep2(_at_)terabites(_dot_)com>
<gep2(_at_)terabites(_dot_)com> wrote:
Simple question... *WHY WAS THE ROUTER/GATEWAY NOT
BLOCKING PORT
25 TO/FROM ALL MACHINES EXCEPT AUTHORIZED INTERNAL MTAS*
??? If your
client had taken that one simple step, none of this
would've happened.
Several issues there.
First, they have at least three or four internal
machines (out of
only about 15) running mail servers. (These servers were
basically
used as a speed buffer/queue for outgoing mail only).
Jeez - how much email does this 15 person company
send??? A reasonable mail server can handle a million
mails an hour - just how much "speed" do they need?
It's less an issue of speed than it is of simply
convenience and auditability. The mail server software
they use is simple freeware "EMWAC", not fancy but it
suits their needs well. They probably send between
600-1000 E-mails per day, as far as their automatically
system-generated ones go. Add to that whatever E-mails
they personally send.
Third, the primary machine involved with their infection
was in
fact one of the machines running not just a mail server,
but a
critical app which does legitimately send E-mails as a
key part of
its job.
So lets get this straight - the mail server was being
used as a desktop machine? I see no other way it could
have been infected with a spam trojan than someone
happened to be using it as a desktop.
That's right. The EMWAC mail server is an additional
function on a machine they already have and are using
(occasionally) as a desktop. That particular machine is
also running an incoming mail processing bot I wrote for
them, which retrieves incoming mail from an external
mailbox, tracks outgoing E-mails and fax-by-mail messages,
scheduling and reissuing them as necessary, routing
various classes of incoming messages, reports on message
deliveries (and non-delivery), eventually deletes
delivered mail from the retry-holding queues, etc etc.
I'm sorry this happened to the company you administer,
but clearly it has taught you some really important
lessons about corporate network security that you can
apply to future contracts. Frankly you should probably
be glad they got CBL listed.
Well, it certainly HAS been a learning experience, but not
so much because I don't understand network security. ;-)
I certainly am even more convinced than before that
wholesale IP address blocking is a terrible solution,
because of the unacceptably blunt nature of the bludgeon.
The other issue, of course, is that IP address blocking is
(again) REACTIVE, and only takes effect AFTER some amount
of worm or spam traffic has been observed. Far better to
instead not deliver the FIRST of the junk.
Also, and I should have replied to that other message
earlier, but on the same lines, there was a question about
when an RBL blacklisting should expire. I would think a
listing should expire some number of hours after the last
such bogus message was seen coming from that host....
rather than having to be removed manually. (And the reset
delay could, for example, be increaed each time a
subsequent infected message from that address (or, better,
machine) is seen.
But again, NAT makes blocking a NAT router a terrible idea
(and worse, depending on how many machines are downstream
from that router).
Gordon Peterson
http://personal.terabites.com
1977-2007 Thirty year anniversary of local area
networking
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
|
|