Topic: HELP - BANDWIDTH ABUSE

[Olsen]

Our SME server 6.0.1 is experiencing some very HIGH volume of outgoing traffic, which is affecting our remote office's latency with data.  I have rebooted the server, and the bandwidth levels return to extrememly high right after reboot.  I have unplugged the eth1 connection and the traffic stops until I plug it back in, then instantly it returns to very high traffic outgoing only.  I have shut all the machines here at our office off, except mine.  Any one know how I can identify what machine or ipaddress is causing our problem????

[cc_skavenger]

run iptraf on the server and turn on one computer at a time.  you can also run this command:
netstat -rC -n | awk '{print $1}' | sort | uniq -c | sort -nr | less

this will show IPs with open connections and the number of connections open...

HTH

[Olsen]

That was nice, however is there a way to show bandwidth usage per ip?

[Olsen]

The problem has something to do with qmail....

When I try to stop qmail, it fails, but when I kill it the outgoing bandwidth stops.  As soon as I start it back up, the outgoing traffic skyrockets again.

Is there someone who hacked our server and is sending mass emails?  Is there anyway I can stop this?

[raem]

Olsen

Install the qmHandle contrib
e-smith-qmHandle-1.0.0-7.noarch.rpm
or
smeserver-qmHandle-1.0.2-9.noarch.rpm

Check the queue in the new server manager panel and delete messages if necessary.
You should also do a virus scan on all workstations to see if you have a active virus infection that is sending out email messages.

[Olsen]

I shut the qmail down all night to see if that would resolve the issue.  I also installed the qmail handler and found 10 messages in remote queue.  Deleted them all and the issue seems to be resolved.  I am having all client computers do virus scans to try to emliminate that as a possible cause as well.

Once again, thanks for the help.

[CharlieBrady]

I shut the qmail down all night to see if that would resolve the issue.

That would only resolve the issue temporarily. Assuming that your problem was excessive mail traffic, you need to discover where the mail traffic was coming from and where it was going to. You have log files to help you to do that, and analysis tools to make sense of the log files.

I also installed the qmail handler and found 10 messages in remote queue.  Deleted them all and the issue seems to be resolved.

Who were the mails from and who to? And how big were they? You need to know those things to prevent it happening again.

[Olsen]

You have log files to help you to do that, and analysis tools to make sense of the log files.

I find it hard to sift through the mail log files to find a trend in them that seem out of the ordinary.  What also makes it difficult is that we have outside sales that log in externally to the webmail and utilize it from other networks.  I am not sure of what analysis tools you are referring to regarding making sense of the log files, but I do refer to the Isoqlog (I think that is what it is called, pretty much a counter of emails sent on any given day)  Nothing seemed out of the ordinary.

Who were the mails from and who to? And how big were they? You need to know those things to prevent it happening again.

The messages in queue did seem strange as they were in the "remote" queue from a user to themself (Example: From: joe@company.com  To: joe@company.com).  The messages were all fairly large (1-3MB) in size.  These were messages they were intentionally sending out so I dont know why they got hung up in the queue.  It is almost like the server was trying to send and resend the email....But I do know that the issue stopped once I removed the messages in queue

I agree that shutting down qmail was a temporary solution, but the deletion of the messages in queue appears to have solved this problem

[judgej]

I encountered a problem like this recently. It was caused by Outlook 2003 on a machine timing out and resending an e-mail. The e-mail was about 3M in size, and it ending up being sent out about 70 times. What I think happened is that Outlook was timning out waiting for an 'okay' from the server, and simply resent the message assuming the connection had been lost.

The timeout, I suspect, was due to the anti-virus programme on that machine being very slow to scan the e-mail.

Anyway - killing the message from the Outbox of that machine, and disabling outgoing e-mail scanning on all machines solved the issue.

-- JJ

[Appesteijn]

I use IpTraf to see which of my internal ip's generate a lot of bandwidth. There is a rpm-contrib for e-smith. Just search for iptraf.