ASL mail relay spoof

Can somebody from Astaro confirm this? (at least from a theoretical standpoint, as soon as possible)

And if it is the case, could somebody from Astaro please post the /sbin/init.d/ipfilter.local entries that will prevent this hack, until an up2date gets published.

Thanks...
  

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
  

So Reed, from what Tom seems to be saying between the lines, the Astaro will in no way initiate a SYN sequence to the victim relay. So the following should not be possible:

Hacker impersonating Spam Target=>???=>Victim Relay using Astaro
(initially, and possibly again during any of the steps that follow)
Victim Relay using Astaro=>SYN=>Spam Target (crucial step!)
Spam Target=>SYN+ACK=>Victim Relay using Astaro
Victim Relay using Astaro=>ACK=>Spam Target

It might respond to spoofs with other sequences, but the spam target should not establish a TCP session based on those wacky packet responses.

If you can get a network trace, I'm sure Tom would have a look. tcpdump or Windows Netowrk Monitor, on a mini-hub (my reseller CD has the tcpdump on the Linux by default, for just such short-notice surprises...)

P.S. I (and Astaro, for that matter!) cannot account for software accepting TCP session creation without an initial SYN. So if there's a tcp stack out there that permits such a thing, it's not Astaro's but that software's problem (going by RFC). Of course if that was ever shown to be the problem in spades, Astaro would probably make some accomodation for an operating system not playing by the rules of the 'net.

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.

Well, those ports should be closed by default.

What's the mail server? If it's Exchange, we can turn on the protocol logging and see what's going on. Exchange has at least three exploits for relaying (two require patches, the other is a weak password issue).

If it's Exchange, the high port number leads me to believe it's the weak password relay problem (because authentication can't occur without the use of those non-privileged ports). Let me know...

And please give a security vendor (be it Astaro or whoever) a chance to patch (48 hours?) before a shout out. Unless you know for a fact it's not common knowledge... (as in: you hear it's happening everywhere)

   

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