unlimited domain web hosting
Discussion forums relating to Web Design and Development
Dealing with a Mail Server Attack (Exim)

 
Post new topic   Reply to topic    Web Design and Development Community Forum Index -> Mail Server Management
View previous topic :: View next topic  
Author Message
Mat
Site Admin


Joined: 17 Mar 2006
Posts: 58
Location: England

PostPosted: Mon Oct 08, 2007 8:42 am    Post subject: Dealing with a Mail Server Attack (Exim) Reply with quote

Stopping an attack on Exim

Attacks on mail servers are pretty common and can lead to mail server outages and even entire server outages.


Common types of attack

There are two common forms of attack ...


Dictionary attack

Email sent to non-existent addresses consisting of random strings of letters representing the usernames (such as dkfjg @ thedomain.com or abcdef @ thedomain.com). This is a very common form of spamming and often you can include email sent to random names generated by the spamming software employed to conduct such attacks.

To reduce the impact and deplete these attacks you must follow the methods detailed in Section 1 below.


Spoofing attack

This is where someone spoofs one of your client accounts' email addresses and sends thousands of spam messages around the net, masses get rejected by recipient mail servers which employ good anti-spam solutions and the rejects get sent to the spoofed address (often a non-existent address, but sometimes an existing mail account).

To reduce the impact and deplete these attacks, you would have to at least set a low mail box quota (let's say a max of 100mb) to prevent complete flooding. Then ensure that Exim is configured to reject any mail at SMTP time that is sent to a full mailbox, because this mail box is certain to completely fill with the high amount of bounces that this attack produces. If you have the benefit of cPanel and WHM then you can make this setting by entering the Exim Configuration Editor (Service Configuration > Exim Configuration Editor in the left hand pane of WHM) and check the box marked ...
Quote:
Reject email at SMTP time for users who have exceeded their quota rather than keeping it in the queue. This is probably a good idea, but it does mean people will lose mail so its not on by default.

Click the save button and Exim will be reconfigured and restarted for the change to take effect**. Now follow the instructions in Section 1 to handle the attack.

**The setting needed in Exim (if you don't have the benefit of WHM's Exim Configuration Editor) is as follows ...
Quote:
virtual_user_maildir_overquota:
driver = redirect
condition = "${perl{checkuserquota}{$domain}{$local_part}{$message_size}}"
user = "${lookup{$domain}lsearch* {/etc/userdomains}{$value}}"
domains = lsearch;/etc/userdomains
data = :fail:Mailbox quota exceeded
allow_fail

... which should be added at the beginning of the section called DIRECTORS CONFIGURATION.

The alternative is to delete the mail account until the rejects subside, so that such mail would be sent to the default/catchall address. You can then follow the instructions in Section 1 to handle the attack.


Section 1

If you’re undergoing a mail attack - the attacks that can be deterred by setting an appropriate catchall (default) address setting

In such circumstances where substantial amounts of email are targeting non-existent addresses it is obviously preferable to set the catchall (default) address to :fail: as this causes the MTA (mail transfer agent - usually Exim) to reject the email at SMTP time - this means that the mail server will refuse to accept and process the email. Many users set the catchall/default address to :blackhole: but the MTA will handle this by accepting the message and then deleting it and this uses resources to do so, whereas using :fail will not use such resources. Other users set the default/catchall address to another email address, either in their account or a remote address but either also uses resources.

So, if you are under such an attack it is obviously preferable to change the default/catchall addresses very quickly to preserve resources and prevent your MTA from going down.


Check if any users are using anything other than :fail: for default/catchall address

To be sure that you need to make any changes its best to see if anyone is using anything other than the desired :fail: setting. You can find this out by running this command in SSH …

Quote:
grep ‘*:’ /etc/valiases/* | egrep -v ‘:fail:’


… if you see no results then all accounts are using :fail: but otherwise you will see a list of all domains which use :blackhole: or have an address set for the default/catchall setting.


Backup all valiases files

You can change all settings to :fail: that do not have it already set, but maybe it would be a good idea to backup the valiases before doing so, so that you can return the settings when the attack subdues. So copy the entire valiases folder to a backup folder for later retrieval - to do this run these two commands in SSH …

Quote:
mkdir /etc/valiasesbackup


… this creates the backup folder, and …

Quote:
cp -p /etc/valiases/* /etc/valiasesbackup


… this copies all files in the valiases folder to the backup folder.


Change all default/catchall addresses from :blackhole: to :fail:

Then to change all default addresses to :fail: we’ll need to run two commands, one to change any :blackhole: settings and the other to change any default addresses that forward to another email address. First run this command in SSH …

Quote:
replace ‘:blackhole:’ ‘:fail:’ — /etc/valiases/*


… this will change any :blackhole: setting to the desired :fail: setting.


Change all default/catchall addresses to :fail:

Then the second command …

Quote:
sed -i ’s/^\*: [^ ]*$/*: :fail: ADDRESS DOES NOT EXIST/g’ /etc/valiases/*


… this will change any setting which sends the unrouted mail to another email address to the desired :fail: setting.

Now, running this command again should reveal no results because we have just changed all settings to :fail: …

Quote:
grep ‘*:’ /etc/valiases/* | egrep -v ‘:fail:’



Restore valiases files

Once the attack is over, you can then copy the backed up valiases files to their usual place, run this command from SSH …

Quote:
cp -p –reply=yes /etc/valiasesbackup/* /etc/valiases


… all done. And this should only take about a minute to complete, depending on your typing or copy and paste skills.
_________________
Mat.

---------------------------------------------------------------------------------------------
Multiple Domain Hosting Plans ~ Domain Name Registration ~ Support
---------------------------------------------------------------------------------------------
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic   All times are GMT
Page 1 of 1

 
Jump to: