spammers are bypassing appliance!

Unanswered Question
Sep 11th, 2007

Greets,

We've run into a problem which is only getting worse; spammers are bypassing our spam appliance, which sits in front of our CiommuniGate Pro server. The only MX Record for our domain points to the appliance, so I'm guessing that these spammers are not performing MX lookups.

We have mobile users we need to support.. we allow them to authenticate against the server, and they are then treated as Client IP's. So we can't lock down SMTP to only accept connections from the appliance.

I realize this isn't really an IronPort problem... the appliance has been incredible, but out users don't "get" it. They're getting spam, so they think something is wrong with the appliance.

Has anyone else here run into this problem? What have you done? Is there something I'm not thinking of which might thwart these spammers?

Thanks for any thoughts,
Reece

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
bfayne_ironport Tue, 09/11/2007 - 20:16

Since CGPro supports LDAP, you should be able to set up SMTP Auth right on the Ironport appliance and then you can just shut off all outside access directly to the backend mail server.

http://www.stalker.com/CommuniGatePro/LDAP.html


Set up two listeners on your appliance.
1 is the MX. If you sent up a sender group that rejects connections from your client PCs on this listener, you can force them to connect to the second listener for SMTP Auth.

Listener 2 would be set up to handle SMTP Authentication. You can even set it up so that non-authenticated connections fall through to a default Sender Group where they are rejected, or highly rate-limited.

There is a lot more to getting it working than a couple of sentences, but the Advanced User Guide should have just about everything you need to get going. The section on LDAP Queries is what you want.

Donald Nash Wed, 09/12/2007 - 21:25

Yes, the spammers are probably doing what I call a "straight-to-A" attack. They're bypassing the MX record and connecting straight to the IP address given by your mail server's A record. We saw this when we deployed our IronPorts three years ago. Our solution was to require SMTP authentication for all mail, not just relay mail, unless it comes from our IronPort MGAs. In other words, any MAIL FROM command that isn't preceded by authentication is rejected with "530 Please authenticate first", unless the SMTP sender is one of our MGAs. This has been completely effective at blocking this sort of attack.

I don't know how versatile CGPro is, so I don't know if it can be adapted to this. If it can be configured to require SMTP authentication for all mail, but can't be configured to disable this based on the sending SMTP's IP address, then there is another way. Require SMTP authentication for all mail, then set up a special username/password for your MGA to use. AsyncOS knows how to do SMTP authentication on outbound connections.

Hope this helps.

redride_ironport Tue, 02/05/2008 - 20:58

I have the same setup and I solve the problem going to CGPro -> settings -> network -> blacklisted ip > 0.0.0.1-255.255.255.255
This setup allows mobile user to authenticate but disables spam going directly to MX.
P.S. Of course you have to include your local network in client ip settings.

steven_geerts Wed, 02/20/2008 - 23:42

Hello,

Since you are stating the CGPro is "behind" your Ironport, I think you can close the internet reach ability for your CGPro host.

it's my experience spammers are delivering spam to "old" mail hosts (not noted in MX records anymore) for months after you removed the hosts IP address from your MX record. Since "valid" (bona-fide) mail servers will always do an MX lookup it's save to disable the CGPro internet connectivity.
If you need to send mail from your Ironport to the CGPro host over the internet you can consider to configure the CGPro host to listen on an alternative port (eg: TCP2525) also configure the Ironport to use this port to deliver messages to the device.

Regards Steven

Actions

This Discussion