Exim under attack?

[adapter]

Hi

i have a high server load and it is Exim i have check exmin_mainlog and i see a lot of these message

2005-04-19 12:30:40 H=(mx4.hotmail.com) [196.2.98.198] F=<[email protected]> rejected RCPT <[email protected]>: no such address here
2005-04-19 12:30:40 H=(mx4.hotmail.com) [196.2.98.198] F=<[email protected]> rejected RCPT <[email protected]>: no such address here
2005-04-19 12:30:40 H=(mx4.hotmail.com) [196.2.98.198] F=<[email protected]> rejected RCPT <[email protected]>: no such address here


how can i stop it? what is doing?

 

[AndyReed]

It is very likely that a script is being exploited. Protecting and securing your server is the best thing you can do to stop these Spammers/hackers.

 

[chirpy]

Looks more like a dictionary attack to me:
http://www.configserver.com/free/eximdeny.html

 

[gahelm]

Chirpy,
I have been using your script and exim acl mods since version 1.0. Worked great! But it isnt working anymore and I cant figure out why. I verified that the mods are still located in the acl section of exim (2nd set of text boxes etc...) the perl script is installed with the proper permissions, the deny file is there, and a symbolic link has been created in cron to run the script. My exim main log which clearly shows a domain being hammered by a dictionary attack never rejects the user, nothing lands in the deny file etc.... My server is being slammed to its knees and I have no idea why this isnt working anymore. Any ideas?

 

[RickG]

... exim main log which clearly shows a domain being hammered by a dictionary attack never rejects the user ...

gahelm: Is it possible this particular domain has the default address set to :blackhole: instead of :fail: ??

If you are not seeing unknown users being rejected in exim_mainlog this could be the problem. Remember that the dictionary attack scripts will have no impact unless you are using :fail: as the default.

Hope this helps.

 

[gahelm]

Thanks for the response. I have already checked to confirm that the default for all domains is set to :fail:. This is ppretty weird, I know it's going to be something stupid, I just need to find it soon.

 

[chirpy]

Check the ownership of the file /etc/exim_deny.lock, if i is owned by root, delete it, and the ACL script should start working again for you.

 

[RickG]

Hmm ... think its worthwhile looking in the actual domain files under /etc/valiases/ ?

It might be redundant ... but is there any chance the domain being slammed with the dictionary attack is a "parked" domain? If so, I think you'd have to look at the actual domain files under /etc/valiases/ to confirm their default is set to :fail:

You might have already done this ...