[Asrg] Re: Asrg Digest, DNSBL BCP v.2.0

[gep2 at terabites.com]

On Sun, 4 Mar 2007 15:17:55 -0500
  Matt Sergeant <msergeant at messagelabs.com> wrote:
> On 4-Mar-07, at 2:18 PM, <gep2 at terabites.com> 
><gep2 at terabites.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