CSF not blocking postfix/smtpd brute force on centOS 7

[Ricky]

Hi,

I recently installed csf on CENTOS 7, however it, it seems it is not able to block postfix/smtpd sasl auth errors.
Here is the log from /var/log/maillog

Code: Select all

Sep 15 14:31:06 LinuxServer postfix/smtpd[26850]: warning: hostname mobiup.climberjumbo.com does not resolve to address 141.98.9.195
Sep 15 14:31:06 LinuxServer postfix/smtpd[26850]: connect from unknown[141.98.9.195]
Sep 15 14:31:07 LinuxServer postfix/smtpd[25442]: disconnect from unknown[92.118.38.52]
Sep 15 14:31:08 LinuxServer postfix/smtpd[25587]: warning: hostname ip-38-52.ZervDNS does not resolve to address 92.118.38.52: Name or service not known
Sep 15 14:31:08 LinuxServer postfix/smtpd[25587]: connect from unknown[92.118.38.52]
Sep 15 14:31:09 LinuxServer postfix/smtpd[26072]: warning: unknown[141.98.9.5]: SASL LOGIN authentication failed: authentication failure
Sep 15 14:31:10 LinuxServer postfix/smtpd[26072]: disconnect from unknown[141.98.9.5]
Sep 15 14:31:10 LinuxServer postfix/smtpd[25876]: warning: unknown[92.118.38.52]: SASL LOGIN authentication failed: authentication failure
Sep 15 14:31:11 LinuxServer postfix/smtpd[25876]: disconnect from unknown[92.118.38.52]
Sep 15 14:31:11 LinuxServer postfix/smtpd[26850]: warning: unknown[141.98.9.195]: SASL LOGIN authentication failed: authentication failure
Sep 15 14:31:11 LinuxServer postfix/smtpd[26850]: disconnect from unknown[141.98.9.195]
Sep 15 14:31:13 LinuxServer postfix/smtpd[32625]: warning: unknown[141.98.9.42]: SASL LOGIN authentication failed: authentication failure
Sep 15 14:31:14 LinuxServer postfix/smtpd[32625]: disconnect from unknown[141.98.9.42]

I have observed for long enough and can say its not blocking these attempts.

I read around and found regex but can't get it work as I am bad at regex.
This is what I found and used:
Added this to to /etc/csf/csf.conf

Code: Select all

CUSTOM10_LOG = "/var/log/maillog"

Added following to /usr/local/csf/bin/regex.custom.pm

Code: Select all

if (($lgfile eq $config{CUSTOM10_LOG}) and ($line =~ /^\S+\s+\d+\s+\S+ \S+ postfix\/smtpd\[\d+\]: warning:.*\[(\d+\.\d+\.\d+\.\d+)\]: SASL [A-Z]*? authentication failed/)) {
    return ("Failed SASL login from",$1,"mysaslmatch","3","25","3600");
}

Can anyone help me to get it working ?

[BallyBasic79]

Ricky, your custom rule appears to function as written, although it may not be what you are expecting.

return ("Failed SASL login from",$1,"mysaslmatch","3","25","3600");

Code: Select all

# The return values from this example are as follows:
#
# "Failed myftpmatch login from" = text for custom failure message
# $1 = the offending IP address
# "myftpmatch" = a unique identifier for this custom rule, must be alphanumeric and have no spaces
-> # "5" = the trigger level for blocking
-> # "20,21" = the ports to block the IP from in a comma separated list, only used if LF_SELECT enabled. To specify the protocol use 53;udp,53;tcp
# "1" = n/temporary (n = number of seconds to temporarily block) or 1/permanant IP block, only used if LF_TRIGGER is disabled

Your trigger level is set at 3, requiring three failures per IP before action. I set my triggers for similar rules at 1 – mostly because I don't have new users trying to log on. Also note that your rule blocks the offending IP from port 25 only. Not sure if that is the port where this action occurs.

I suggest you change the trigger to 1 and leave the port undefined to block them from all. You might also consider a longer block, such as a day (86400). HTH.

[Ricky]

Thanks for the insight, any suggestion how do I leave port blank ?

[BallyBasic79]

Suggested:

Code: Select all

    return ("Failed SASL login from",$1,"mysaslmatch","1","","86400");

[Ricky]

I guess the port was the issue, leaving port that way worked and now I am seeing it in action. Thanks for the suggestion.

[BallyBasic79]

I originally understood the issue as the rule was not being triggered. So the rule was actually being triggered before, but just not blocking continued attempts? Correct?

[Ricky]

I guess rule was correct but specifying PORT 25 was not triggering it, they may be using other ports, so when we omitted PORT from it (as per your suggestion), it started working.