undecipherable characters in exim_mainlog

[jols]

I am guessing this is some form of DDOS attack, the IPs in question are apparently not sending out email, but we are seeing entires like the following, approximately once every 20 entries:

2013-09-20 20:17:15 SMTP ␌⎺┼┼␊␌├␋⎺┼ °⎼⎺└ [181.67.224.145]:63035 (TCP/IP ␌⎺┼┼␊␌├␋⎺┼ ␌⎺┤┼├ = 8)
2013-09-20 20:17:15 ┼⎺ ␤⎺⎽├ ┼▒└␊ °⎺┤┼␍ °⎺⎼ IP ▒␍␍⎼␊⎽⎽ 181.67.224.145

Any ideas what this could be, or what countermeasures we may be able to evoke against this?

Thanks much.

 

[jols]

UPDATE - I made out a cPanel.net ticket. Response came back that this was the result of some sort of exploit attempt, and some of it may be due to my shell client not being able to properly resolve some of the characters in the log files; to use the "less" command instead of tail. Good advice, but nevertheless these very strange exploit attempts continue. Usually one of the following is included in the log entries in question, but not always:

too many unrecognized commands

or

too many syntax or protocol errors

Such exploits are now coming in hot and heavy on two of our servers, in some cases causing email delivery to be delayed. I have cobbled together a shell script to "look for" either of the above phrases in exim_mainlog, and then block the IP in the same log entry. But this is purely a Bandaid approach. So I am wondering if there is something a bit further up the chain that we could do, i.e. before Exim even has a chance to reject this nonsense. In other words, I'd certainly like to block these attempts before they start taxing the Exim system. Anyone?

 

[cPanelMichael]

Hello

The following threads should be useful to you:

Exim ACL Block Buffer Overflow Attack
Sustained Exim Attack

Thank you.

 

[jols]

Thanks much.

I tried the suggestion listed in Sustained Exim Attack, but for me at least this had absolutely no effect.

The other suggestion pertains more to keeping the log file small, which is not much of an issue on our case.

What I ended up doing, was cobbling together a script to "look for" certain phrases in the exim_mainlog, and then blocking the IP address in the same log entry. However, this kind of reactive, rather than preventative approach is not very appealing.

Thanks again.