flyinace2
asked on
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?
ASKER
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?
Spambots, zombies, contaminated CIDR, bad reputation provider. Entry created 2011-01-29
What does that tell you?
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?
Anything showing up on mxtoolbox?
ASKER
nope. A few timed out....but otherwise, all clear
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.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Results of open relay test:
HELO please-read-policy.mxtoolb ox.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
HELO please-read-policy.mxtoolb
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
If you were an open relay - you would be blacklisted all over the place.
Just wanted to rule open relay out. It's a basic test anyways.
Sure - I understand - but the evidence is already there to rule that one out.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
@jrwarren - See comment http:#a34901546 posted 15 minutes ago! Please read the entire thread before posting.
Thanks
Alan
Thanks
Alan
ASKER
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....
The queue does not contain any messages in queue....
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?
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?
ASKER
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?
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.
IP address: 66.94.237.64
Reverse DNS: mta-v3.mail.vip.mud.yahoo.
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.
ASKER
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?
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)?
Have any of your users been sending large messages to friends on yahoo with big attachments in them (read pictures)?
ASKER
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!
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!
: ) - 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.
Glad it is resolved.
If listed - find out why you are listed and then based on that info - the next step can be determined.