Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1032
  • Last Modified:

SBS 2008 sending tremendous SMTP

In our office we have about 12 computers and a SBS 2008 box that is our mail, DNS, DHCP etc…In the past few days we noticed our internet slowed dramatically so I installed wireshark on the SBS 2008 box. I’m seeing a TREMENDOUS amount of SMTP traffic going out to just a few IPs (this traffic is going nonstop). I have a feeling we must have picked up a virus or botnet or something. Is there something obvious that I can do to kill this SMTP traffic while keeping my server up? Is there an obvious place I can look to get rid of whatever we may have picked up?
0
flyinace2
Asked:
flyinace2
  • 10
  • 7
  • 2
  • +1
2 Solutions
 
Alan HardistyCommented:
If you have picked up a nasty - check you are not blacklisted on www.mxtoolbox.com/blacklists.aspx and www.blacklistalert.org

If listed - find out why you are listed and then based on that info - the next step can be determined.
0
 
flyinace2Author Commented:
My server is blocked only on APEWS.ORG Databasetest. The reason is:CASE: C-813
Spambots, zombies, contaminated CIDR, bad reputation provider. Entry created 2011-01-29

What does that tell you?
0
 
Alan HardistyCommented:
Entry created 2011-01-29!  2 weeks old - which could mean you had a problem and it has been dealt with or you had a problem begin on the 29th and it is still a problem, but if it were still a problem, you would be listed on more than just APEWS.

Anything showing up on mxtoolbox?
0
VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

 
flyinace2Author Commented:
nope. A few timed out....but otherwise, all clear
0
 
connectexCommented:
Have you confirmed it's the server not an open relay yet? You can use: http://mxtoolbox.com/diagnostic.aspx. Have you created any Exchange send connectors? What connectors do you have? They are in your Exchange Management Console->Server Configuration->Hub Transport and on the Receive connectors tab.
0
 
Alan HardistyCommented:
If you are not on any other lists - you should not be sending out spam.

Check your queues on the server using Exchange Management Console> Toolbox> Queue Viewer> Open Tool.

Do you have a busy queue?
0
 
flyinace2Author Commented:
Results of open relay test:
HELO please-read-policy.mxtoolbox.com
250 remote.XXXXXX.com Hello [64.20.227.133] [78 ms]
MAIL FROM: <supertool@mxtoolbox.com>
250 2.1.0 Sender OK [250 ms]
RCPT TO: <test@example.com>
550 5.7.1 Unable to relay [5382 ms]
QUIT
0
 
Alan HardistyCommented:
If you were an open relay - you would be blacklisted all over the place.
0
 
connectexCommented:
Just wanted to rule open relay out. It's a basic test anyways.
0
 
Alan HardistyCommented:
Sure - I understand - but the evidence is already there to rule that one out.
0
 
jrwarrenCommented:
hello.

Start --->  All Programs ---> Microsoft Exchange ---> Server Management Console
     Select Toolbox
In the right hand pand select Queue Viewer
   Let us know what you have in there and the dates of the messages.
0
 
Alan HardistyCommented:
@jrwarren - See comment http:#a34901546 posted 15 minutes ago!  Please read the entire thread before posting.

Thanks

Alan
0
 
flyinace2Author Commented:
I have 1 send connector which is used to send mail from our server to the rest of the world.
The queue does not contain any messages in queue....
0
 
Alan HardistyCommented:
Okay - if the server is not sending the mail, then what is?

Do you have your firewall locked down so that only the SBS 2008 server can send out SMTP traffic (TCP Port 25) and all other internal IP addresses are blocked?
0
 
flyinace2Author Commented:
I am now using my firewall to block all outbound traffic to 66.94.237.64 which seems to have help a lot (perhaps solved the problem). Can anyone see a downside to this?
0
 
Alan HardistyCommented:
IP Information - 66.94.237.64

IP address:                     66.94.237.64
Reverse DNS:                    mta-v3.mail.vip.mud.yahoo.com.
Reverse DNS authenticity:       [Verified]
ASN:                            14780
ASN Name:                       INKTOMI-LAWSON
IP range connectivity:          2
Registrar (per ASN):            ARIN
Country (per IP registrar):     US [United States]
Country Currency:               USD [United States Dollars]
Country IP Range:               66.88.0.0 to 66.95.255.255
Country fraud profile:          Normal
City (per outside source):      Sunnyvale, California
Country (per outside source):   US [United States]
Private (internal) IP?          No
IP address registrar:           whois.arin.net
Known Proxy?                    No
Link for WHOIS:                 66.94.237.64

Might be a problem - it is a yahoo / inktomi IP address.

Better to block ALL internal IP's for port 25 outbound except the SBS 2008 server.
0
 
flyinace2Author Commented:
Ok, but wireshark showed that the traffic was originating from my server and going to 66.94.237.64. Doesn't that mean that the traffice was coming from the server and not other computers?
0
 
Alan HardistyCommented:
Okay - so if the server is sending SMTP traffic to Yahoo and you are not blacklisted - it suggests that the traffic might be genuine.

Have any of your users been sending large messages to friends on yahoo with big attachments in them (read pictures)?
0
 
flyinace2Author Commented:
OK, The problem is solved!!!!!
There actually was a message in the queue, it just took a minute to load (that is why I said there were none)...And guess what domain the message was addressed to? Yahoo! I pulled that message out of the queue and now everything seems to be fine again...THANKS EVERYONE!
0
 
Alan HardistyCommented:
: ) - Go find your user who sent it and beat them around the head with a large chair-leg.  Or alternatively, remind them not to send massive emails out and possibly cap the server.

Glad it is resolved.
0

Featured Post

[Webinar] Cloud and Mobile-First Strategy

Maybe you’ve fully adopted the cloud since the beginning. Or maybe you started with on-prem resources but are pursuing a “cloud and mobile first” strategy. Getting to that end state has its challenges. Discover how to build out a 100% cloud and mobile IT strategy in this webinar.

  • 10
  • 7
  • 2
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now