Account getting thousands of mails per day (dictionary attack).

ChemicalWH

Active Member
Mar 4, 2004
40
0
156
Hey, here's the problem:

1 of the accounts on one of my servers is getting up to 10 thousand mails per day, all routed to addresses like this:

tail -100 exim_mainlog | grep blackhole
2005-11-12 02:43:01 1EakQ0-0008DH-Aw => :blackhole: <[email protected]**.com> R=virtual_aliases
2005-11-12 02:43:01 1EakQ0-0008DH-Aw => :blackhole: <[email protected]**.com> R=virtual_aliases
2005-11-12 02:43:01 1EakQ0-0008DH-Aw => :blackhole: <[email protected]**.com> R=virtual_aliases
2005-11-12 02:43:01 1EakQ0-0008DH-Aw => :blackhole: <[email protected]**.com> R=virtual_aliases
2005-11-12 02:43:01 1EakQ0-0008DH-Aw => :blackhole: <[email protected]**.com> R=virtual_aliases
2005-11-12 02:43:01 1EakQ0-0008DH-Aw => :blackhole: <[email protected]**.com> R=virtual_aliases
2005-11-12 02:43:01 1EakQ0-0008DH-Aw => :blackhole: <[email protected]**.com> R=virtual_aliases
2005-11-12 02:43:01 1EakQ0-0008DH-Aw => :blackhole: <[email protected]**.com> R=virtual_aliases
2005-11-12 02:43:01 1EakQ0-0008DH-Aw => :blackhole: <[email protected]**.com> R=virtual_aliases
2005-11-12 02:43:01 1EakQ0-0008DH-Aw => :blackhole: <[email protected]**.com> R=virtual_aliases
2005-11-12 02:43:01 1EakQ0-0008DH-Aw => :blackhole: <[email protected]**.com> R=virtual_aliases
2005-11-12 02:43:01 1EakQ0-0008DH-Aw => :blackhole: <[email protected]**.com> R=virtual_aliases
2005-11-12 02:43:01 1EakQ0-0008DH-Aw => :blackhole: <[email protected]**.com> R=virtual_aliases
2005-11-12 02:43:01 1EakQ0-0008DH-Aw => :blackhole: <[email protected]**.com> R=virtual_aliases
2005-11-12 02:43:01 1EakQ0-0008DH-Aw => :blackhole: <[email protected]**.com> R=virtual_aliases
2005-11-12 02:43:04 1EakQ3-0008DH-TE => :blackhole: <[email protected]**.com> R=virtual_aliases
2005-11-12 02:43:04 1EakQ3-0008DH-TE => :blackhole: <[email protected]**.com> R=virtual_aliases
2005-11-12 02:43:04 1EakQ3-0008DH-TE => :blackhole: <[email protected]**.com> R=virtual_aliases
2005-11-12 02:43:04 1EakQ3-0008DH-TE => :blackhole: <[email protected]**.com> R=virtual_aliases
2005-11-12 02:46:01 1EakSt-0008Gd-De => :blackhole: <[email protected]**.com> R=virtual_aliases
2005-11-12 02:46:07 1EakSy-0008Gb-Vh => :blackhole: <[email protected]*.com> R=virtual_aliases
2005-11-12 02:46:07 1EakSy-0008Gb-Vh => :blackhole: <[email protected]*.com> R=virtual_aliases
2005-11-12 02:46:07 1EakSy-0008Gb-Vh => :blackhole: <[email protected]**.com> R=virtual_aliases
2005-11-12 02:46:07 1EakSy-0008Gb-Vh => :blackhole: <[email protected]**.com> R=virtual_aliases
2005-11-12 02:46:07 1EakSy-0008Gb-Vh => :blackhole: <[email protected]*.com> R=virtual_aliases


As you can see, the mails go directly to :blackhole: because there's no excisting address in the mails, and the catch all has been set to :blackhole:.

Even though these thousands of e-mails go to /dev/null immediatly it's still causing quite some stress on the server, and its making the log files really really big.

I've discussed the matter with the customer who owns the account and he has absolutely NO idea where the mails come from, or why they're getting them. The mailing has been going on for months now, always from different hosts/ip addresses.

There's a few mail accounts from that certain domain that can't be deleted, so taking off the MX record is not a solution. I was wondering if anyone here would have a solution to either stop these attacks or route them somewhere non-existing without losing the mail accounts that my customer wants to keep.
 

ChemicalWH

Active Member
Mar 4, 2004
40
0
156
Changes made, i have yet to find out if it actually makes a big difference.

I'll let you know
 

rpmws

Well-Known Member
Aug 14, 2001
1,787
9
318
back woods of NC, USA
ChemicalWH said:
Changes made, i have yet to find out if it actually makes a big difference.

I'll let you know
if you change the :blackhole: to :fail: and watch the exim_mainlog you will see the server never even opens the door where before it accepts the emails, scans them, processes filters and aliases and then clobers them to /dev/null. What a waste. spammers will give up eventually if you :fail: on them.
 

ChemicalWH

Active Member
Mar 4, 2004
40
0
156
Well, what i CAN tell you is that the serverload has been lower than the it has been the last 6 months, so i'm quite certain that the whole thing has made a difference.

Chirpy, if that's your software.. THANK YOU.


Ruud
 

PMH-Steve

Registered
Aug 12, 2004
4
0
151
Ok I have a question:

Whenever we have a user getting mailbombed like this and they set their default to :fail: we end up with thousands and thousands of failure bounce emails in the queue. When we set it to :blackhole: we don't have that problem anymore?

If using :fail: doesn't open a connection or use disk resources then why does the queue fill up and bog down the server with these :fail: generated notices?

I think what is happening is that the :fail: bounce message that is going out to these fake spammer addresses must get bounced back to us (because the addresses we are sending :fail: messages too are emails that don't exist in the first place - [email protected] or something). The mail queue ends up overflowing (average is like 10,000 messages) and before you know it 50 tickets are sent in with people having mail problems on that server.

In that case it seems :blackhole: is the better option for us. The dictionary attack ACL seems like a good idea regardless but I'm just curious about this :fail: vs :blackhole: debate as everytime we have this mailbomb thing happen and the server is bogged down it's almost always due to the targeted user having :fail: set as their default. Changing :fail: to :blackhole: and clearing the mail queue fixes the issue (or so it seems for the past few months).

I've been through this scenario probably 30 times in the last 6 months (out of 100 cpanel boxes). After changing to :blackhole: and explaining to the customer what happened everything has been fine since.

Thanks.
 
Last edited:

rpmws

Well-Known Member
Aug 14, 2001
1,787
9
318
back woods of NC, USA
PMH-Steve said:
Ok I have a question:

Whenever we have a user getting mailbombed like this and they set their default to :fail: we end up with thousands and thousands of failure bounce emails in the queue. When we set it to :blackhole: we don't have that problem anymore?

If using :fail: doesn't open a connection or use disk resources then why does the queue fill up and bog down the server with these :fail: generated notices?

I think what is happening is that the :fail: bounce message that is going out to these fake spammer addresses must get bounced back to us (because the addresses we are sending :fail: messages too are emails that don't exist in the first place - [email protected] or something). The mail queue ends up overflowing (average is like 10,000 messages) and before you know it 50 tickets are sent in with people having mail problems on that server.

In that case it seems :blackhole: is the better option for us. The dictionary attack ACL seems like a good idea regardless but I'm just curious about this :fail: vs :blackhole: debate as everytime we have this mailbomb thing happen and the server is bogged down it's almost always due to the targeted user having :fail: set as their default. Changing :fail: to :blackhole: and clearing the mail queue fixes the issue (or so it seems for the past few months).

I've been through this scenario probably 30 times in the last 6 months (out of 100 cpanel boxes). After changing to :blackhole: and explaining to the customer what happened everything has been fine since.

Thanks.
Back about a year ago this used to be the case. I remember cause that's why I used blackhole. But now :fail: will simply stop the process dead in the water ..or it should anyway.

Try setting your default box to :fail: and send to a bad address and tail the mail exim_mainlog and watch what happens. If you want put a fake "from" on the email you send and see if the failure bounce winds up in queue.
 

lloyd_tennison

Well-Known Member
Mar 12, 2004
697
1
168
Yes. If you read the notes on chirpy's script it tells all abut it and the change.