ASL mail relay spoof

Sorry, but this is not true. While IP spoofing may cause ASL to send packets to the spoof victim (this is a general networking effect, not ASL specific), this has nothing to do with being an "open relay".

If your ASL was or is an open relay, here are the possible reasons:

- incorrectly configured proxies ("Any" in allowed networks)
- using proxy auth with misconfigured SAM or RADIUS auth types
- "creative" NAT rules (port bouncers)

regards,

/tom
  

Hmmm!  The person who discovered this (it wasn't me) is a highly skilled engineer with CISSP and CEH certifications.  I have no reason to doubt his skills and judgment, but he's not infallible either.  What precipitated his investigation was a threat from the ISP to shut down the Internet connection due to repeated spamming.  The packets were traced to the Astaro box.  We went over all the settings together and there was nothing amiss, nor was there anything unusual.  The box does not have SMTP proxy turned on, and the existing rules seem to be fine.  I know Astaro is looking into this, we're doing what we can here to try to trace this out further, but so far nothing points to a faulty setup. 

I agree that packet spoofing isn't, by definition, being an open relay, but in this case the effect is exactly the same.  Spoofed packets were reflected off of the external interface and into port 25 of a victim mail server.  To the victim mail server, the Astaro box became the source of a stream of spam.

New information:  he was able to thwart the attack by inserting a filter rule that blocked anything above port 1024.

I don't believe the network has a mail server, but I'll check.

Sorry about posting this here, my clear understanding from Astaro engineering was that they preferred that issues be posted in the UBB for the fastest action.  This was a potentially hot issue, so I posted it here.  I'll try to be more cautious in the future, the concern is fully understandable.

-Steve 

If they have Win2K or IIS, there is sometimes a native SMTP server.

I know you meant well about the post; I was Mr.Nice Guy and once went to a big vendor (about an SMTP relay issue, as a matter of fact!), only to be told "well, to fix that will break functionality that our customers have come to expect..." Needless to say, they don't even enterrtain such a notion now.

A vendor should get up to 48 hours, unless it can make a case to the reporter that they're really trying and can't realistically deliver on a solution in that time...

[I have my doubts about you-know-who's monthly patching thing; they still don't understand (or accept?) that the age of a patch is the issue...]
    

OK, some more information.  This is a test network and there is no mail server, or a need for mail service coming or going.  A slight correction to my last posting:  the way they stopped the attack was to deny ingress traffic above port 1024 on a BORDER ROUTER ahead of the Astaro.  On the Astaro itself, since there is no need for mail, he denied anything coming from source port 25 destined to the firewall external interface.  There are logs showing all this in great detail, I'll forward them to Astaro engineering later today.

Steve. 

Forgive me if you are aware of this, though:
even though there is no mail server, the SMTP service can be sometimes installed on Windows server boxes (for example, as part of IIS)
  

this has become the industry standard on how to notify vendors about expoitable holes that need to be patched:

http://www.wiretrip.net/rfp/policy.html 

Looks good, except the five day thing; unless I missed a clause in another section, I would add that all bets are off if the exploit is "common knowledge" in the hacker community.

What's "common knowledge"? That's not always a black and white classification, but one clear-cut criteria is if it's been posted on a publicly accessible site (like packetstorm).

Once I get the info on how an exploit works, in most cases I can go about taking measures to cordon off that exploit.
  

I wouold agree as well.  Normally if you have found a exploit, you can find out if it common knowledge based on what you know about how it works and what is involved.  More than likely if it is common knowledge as fast as things move now a days it will have already been patched.

from the FAQ section:
Q. I'm a software maintainer, and I can't possibly fix the problem in 5 days....
A. You don't have to. If you (re)read the above, you have 5 days to establish communication. Provided you cooperate with the researcher and keep them 'in the loop', they should provide you with whatever time necessary to resolve the ISSUE (within fair reason).


They just want you to respond in 5 days and not act like a lot people do with the attitude that the person reporting the problem is crazy and there CAN'T be a problem with your application.
 

Heavy sigh.

I was just informed that this issue has been resolved.  The sysadmin responsible for the inside network found Klez, killed it, and then the problem of course disappeared.  

While this is certainly a relief, I am truly sorry for the hysteria this issue brought upon all of us.  

Happy Turkey Day, folks.

-Steve 

No problem; I'm kinda of embarressed myself for not having postulated that as another possibility: a trojan with its own SMTP stack...
  

Mext time before you write in this forum check yours computers for virus behinds the firewall. Many people in here can be afraid if you not have facts about bugs in ASL. 

Mext time before you write in this forum check yours computers for virus behinds the firewall. Many people in here can be afraid if you not have facts about bugs in ASL.