Exchange server ip address blocked by anti spamware comapnies

[Bryanhickman7777]

Our exchange email server has had its IP address blocked for the second time by anti spamware companies.

Originally we changed our web provider to exanetworks from BT.

They gave us a new ip and the problems began.

We assumed that they gave us an IP that had been previously used by some kind of spamware company, hence the reason for it being blocked.

A quick phone call and new IP later we have been fine for 4 months.

Now the same problem is occurring again.

 

Here is the exact error message.

 

DB3FFO11FD060.mail.protection.outlook.com rejected your message to the following e-mail addresses:

deleted by poster

DB3FFO11FD060.mail.protection.outlook.com gave this error:

Service unavailable; Client host [deleted by poster] blocked using Spamhaus; To request removal from this list seeBlocklist Removal Center - The Spamhaus Project

Your message wasn't delivered due to a permission or security issue. It may have been rejected by a moderator, the address may only accept e-mail from certain senders, or another restriction may be preventing delivery.

 

Diagnostic information for administrators:

Generating server: deleted by poster

 

DB3FFO11FD060.mail.protection.outlook.com #550 5.7.1 Service unavailable; Client host [194.247.236.188] blocked using Spamhaus; To request removal from this list see http://www.spamhaus.org/lookup.lassAt the minute it appears to have only been restricted to microsoft emails (hotmail), but i do not want to go through the head ache of changing ip address again.

 

I can only assume that one of the exchange accounts is receiving alot of spam, or sending spam.

Has anyone else had this issue?

Any advice is appreciated.

[localzuk]

As you left the IP in the second bit, I looked it up - The CBL

 

"This IP is infected (or NATting for a computer that is infected) with the cutwail spambot. In other words, it's participating in a botnet.

 

Cutwail is a complex infection and requires a number of steps to ensure that it's eradicated."

[Bryanhickman7777]

Hello friend,

I read that, but I'm not 100% convinced our network is infected.

But if it is, is this process going on automatically without anybody's knowledge?

Or does it require human interaction?

[localzuk]

Its saying your server is part of a botnet - so it'd be entirely automatic. Also, as its the CBL, its a specific botnet too. They very rarely get it wrong on the CBL I'd say, as their methodology is honed to detecting that type of spam.

 

Have you tried running the linked Norton Power Eraser tool?

 

Also, is that public IP actually being presented through NAT? Or is it a direct routed IP? If its NAT, it means it could be any device in the network that is behind that IP that is doing the spamming.

[Bryanhickman7777]

Its saying your server is part of a botnet - so it'd be entirely automatic. Also, as its the CBL, its a specific botnet too. They very rarely get it wrong on the CBL I'd say, as their methodology is honed to detecting that type of spam.

 

Have you tried running the linked Norton Power Eraser tool?

 

Also, is that public IP actually being presented through NAT? Or is it a direct routed IP? If its NAT, it means it could be any device in the network that is behind that IP that is doing the spamming.

 

The norton power tool was ran on the exchanger server, then auto restart.

It's nat I'm afraid, but luckily there's only about ten machines including the servers.

[Bryanhickman7777]

I forgot to mention, one of the servers is a terminal server, that hosts remote sessions.

Is this a problem?

[ijk]

Hello,

Configure your firewall to accept SMTP and DNS outbound connections only from your Exchange server and DNS servers. Then watch the list @localzuk mentioned. If none of these machines are producing the offending traffic then the time the activity was last seen will drift away into the past and you can use their delisting procedure. Obviously, if any of these machines are then you need to deal with it. I guess its more likely that one of your workstations is producing the traffic (the CBL is showing that the activity was last seen 5 hours ago. It's now 9 ish so that means the last activity was seen around 4. Assuming your servers are still on and you haven't cut the internet connection).

In which case you can configure your firewall first thing and hopefully the offending machine won't be booted before you have (maybe you can do it remotely this evening).

Then you can watch for these kinds of connections in your firewall logs and maybe you'll track it down, but don't count on it.

Additional steps to take once you've stopped the problem leaking to the internet are configuring the individual workstation firewalls to disallow SMTP and allow DNS only to the DNS servers. You could also get the workstations to log dropped packets of this type and forward those events (I'm kind of assuming a Windows environment here) to one of your servers so you can monitor the activity centrally.

Hope that helps, and all the best.

Nic

[Bryanhickman7777]

Hello,

Configure your firewall to accept SMTP and DNS outbound connections only from your Exchange server and DNS servers. Then watch the list @localzuk mentioned. If none of these machines are producing the offending traffic then the time the activity was last seen will drift away into the past and you can use their delisting procedure. Obviously, if any of these machines are then you need to deal with it. I guess its more likely that one of your workstations is producing the traffic (the CBL is showing that the activity was last seen 5 hours ago. It's now 9 ish so that means the last activity was seen around 4. Assuming your servers are still on and you haven't cut the internet connection).

In which case you can configure your firewall first thing and hopefully the offending machine won't be booted before you have (maybe you can do it remotely this evening).

Then you can watch for these kinds of connections in your firewall logs and maybe you'll track it down, but don't count on it.

Additional steps to take once you've stopped the problem leaking to the internet are configuring the individual workstation firewalls to disallow SMTP and allow DNS only to the DNS servers. You could also get the workstations to log dropped packets of this type and forward those events (I'm kind of assuming a Windows environment here) to one of your servers so you can monitor the activity centrally.

Hope that helps, and all the best.

Nic

 

Thank you, will try this tomorrow and publish the results.

[jamesfed]

Another option for your outbound mail would be to use a mail relay provided by your ISP/service provider.

 

That way you shouldn't have to worry about looking over your own servers reputation.

[Max_Power]

We have had a similar issue late last year and it was a machine on the network with the SPAMbot on it not the actual exchange server, no anti virus detected its presence when it somehow go into the network.

 

After doing a full scan of the network and finding nothing, we de-listed our IP, only for it to happen again, the CBL reported what time they felt it happened and we scanned machines and users logged in at this time, cross referencing it against the Smoothwall logs. Hey presto was a PC in an office that wasnt turned on when we did the original scan and found that user using it had irregular internet traffic through smoothwall which coincided with the block time enforced by CBL, rebuilt the PC scanned user account and completely reset it, removed IP from CBL list and jobs a good en.

 

Be careful when you clear your IP from the CBL they will only allow you to do it a certain number of times and then you get blacklisted permanently if the issue reoccurs and you have to jump through some serious hoops to get off the list.

 

Good luck in finding cause, let us know how you get on.

[truebluesteve]

I had this a couple of years ago and it turned out to be the assistant bursars PC - she had opened a file attachment from "Royal Mail" in Outlook. In the end it didn't take too long to find - it was just a case of watching the SMTP traffic on the Smoothwall box when it was quiet and tracking down the source IP address.

 

It is a pain but the advice above is all good!