SOLVED Difference between alerts?

[kabatak]

1. What's the difference between:

RELAY Alert
LOCALHOSTRELAY Alert
AUTHRELAY Alert
LOCALRELAY Alert

2. I am currently getting "RELAY Alert" presumably from a compromised account, however even after changing the email account's password the alert keeps on happening, any suggestions?

 

[rpvw]

Your Relay Alert is probably from an external account, so changing your receiving account password is unlikely to help.

From the .knownhost.com/wiki/security/csf-lfd/notifications
Common Notifications from CSF/LFD

Relay Alert
A "Relay Alert", as opposed to the Authrelay, Poprelay, Localrelay, or Localhostrelay alerts, is triggered by "external mail", that is, messages that are coming from another mailserver. Usually these are incoming messages. Although they are not usually indicative of spam being generated within the server, if enough messages are coming from the same IP address quickly enough to trigger this alert type, it is probably worth looking into why they are sending so much mail, and determine if there is anything that needs to be adjusted.

Authrelay Alert
An "Authrelay Alert" is triggered by "email authenticated by SMTP AUTH". This is one method logging into the mailserver to send messages. Most modern mail clients log in by this method. If these messages should not be sent or should not be sent this quickly, then that email address is likely to need a new password, since whoever is sending the messages demonstrably has the current password.

Poprelay Alert
A "Poprelay Alert" is triggered by "email authenticated by POP before SMTP". Some older mail clients authenticate using this method, but it is recommended to use SMTP AUTH instead, in part because it makes the logs clearer which makes it easier to find causes of spam issues or similar if they occur.

Localrelay Alert
A "Localrelay Alert" is triggered by "email sent via /usr/sbin/sendmail or /usr/sbin/exim". This is usually done by scripts. If a script is sending too much mail, it will need to be reconfigured accordingly. If a script is sending mail that it shouldn't, it will need to be disabled or fixed so that it only sends the messages that it should.

Localhostrelay Alert
A "Localhostrelay Alert" is triggered by "email sent via a local IP address". This means that the message is coming from within the server. If messages are being sent from within the server without authenticating, then changing email passwords will not prevent them from being sent. If the messages are not authorized, the source of the message will need to be found and stopped.

 

[kabatak]

Your Relay Alert is probably from an external account, so changing your receiving account password is unlikely to help.

This is confusing, if Relay Alert is incoming emails from an external server then does that mean there's nothing we can do about it?

BTW here's the alert I got:

[INDENT]Time:  Sun Oct 15 13:57:02 2017 +0800
Type:  RELAY, Remote IP - 111.179.74.55 (CN/China/-)
Count: 101 emails relayed
Blocked: No

Sample of the first 10 emails:


2017-10-15 13:00:46 1e3b2b-003reZ-Rs <= [email protected] H=(jsgh.org) [111.179.74.55]:52973 P=smtp S=1085 [email protected] T="" for [email protected]
2017-10-15 13:01:18 1e3b38-003rfy-6j <= [email protected] H=(mail.10000hotel.cn) [111.179.74.55]:53129 P=smtp S=1257 [email protected] T="" for [email protected]
2017-10-15 13:01:48 1e3b3b-003riz-Rj <= [email protected] H=(xinyiglass.com) [111.179.74.55]:53282 P=smtp S=1094 [email protected] T="" for [email protected]
2017-10-15 13:02:19 1e3b47-003rl5-6g <= [email protected] H=(seuic.com) [111.179.74.55]:53437 P=smtp S=1226 [email protected] T="" for [email protected]
2017-10-15 13:02:51 1e3b4d-003rn0-Ep <= [email protected] H=(huayechuchen.com) [111.179.74.55]:53592 P=smtp S=1254 [email protected] T="" for [email protected]
2017-10-15 13:03:54 1e3b5e-003rqP-FF <= [email protected] H=(venice666.com) [111.179.74.55]:53900 P=smtp S=1243 [email protected] T="" for [email protected]
....
[/INDENT]

Note: example.com is a Cpanel account in our server while qq.com and the other domains are not from our server. What do you make of it?

 

[rpvw]

Your alert is being triggered by over 100 emails (101) in the past hour from the qq.com domain (note that all the user-names before the @ are just random numbers) being received by your server for delivery to your email user [email protected]

In the sample you posted - the mails are being sent from the IP 111.179.74.55 which is reported to be in China, and which may not necessarily have anything to do with the qq.com domain, the sender domain is trivial to spoof.

It is likely that a script is running on, or through, the server or device that is using the IP 111.179.74.55.

This device may be a genuine mail-server that has been compromised by a script, or that has had an email account compromised, or it may be any device connected to the internet that is being levered for bulk mail, either knowingly, or because it has been exploited.

There is little you can do other than to block all mails from qq.com and/or from the IP that you are seeing. However, the spammers usually rapidly change both their IP's and their spoofed domains, so you may be chasing them for some time !

The recommended way to limit the impact of this type of spam (which is almost email ddos) is to enable greylisting to eliminate non genuine mail-servers from getting through, and by configuring your CSF to suit your hardware environment and your clients. You may want to adjust the CSF configuration Relay Tracking section to trigger on a lower setting and to block for longer periods. If you do change settings, monitor the results carefully to ensure you are not getting too many false positives that block genuine mail senders.

Take note that the default setting for CSF 'Relay' is to NOT block incoming mails, but rather to just send you an alert that something unusual is happening.

Remember that bulk spam you receive because some user somewhere had their email account, server, or device hacked or compromised (however they achieved it) is a constant reminder to you to ensure both you, and your clients, follow best practices and set passwords that are non dictionary, nor trivial to guess.

 

[kabatak]

@rpvw Thanks. Is it safe to say that no email account is compromised within our server? Because I've change cpanel and email passwords already, still email keep coming. Also, the public_html folder of the cpanel account has no malicious scripts (just basic HTML page).

I have enabled Cpanel Greylisting, seems to catch it (the reports tab is flooded with that IP 111.179.74.55).

How do I block the offending external IP 111.179.74.55 from ever sending email to us on a system level?

 

[rpvw]

I think it is unlikely that your email account is currently compromised. (But keep checking, anything can happen in the future )

You can use the Exim Blacklist to refuse all SMTP traffic from an IP
WHM >> Service Configuration >> Exim Configuration Manager
Basic Editor
Access Lists
Blacklisted SMTP IP addresses (IP addresses from which SMTP connections are dropped unconditionally)

 

[cPWilliamL]

I'm glad to see @rpvw was able to help. It's also worth noting these alerts are not from cPanel, but from the 3rd-party firewall CSF(ConfigServer Community Forum - Index page). You may find more detailed assistance directly in their forums.