[arch-general] Automated check log and block postfix
Hello, happy new year first :) I have questions about postfix and the logfile. I have often player which try using submission which come in log like: Jan 1 11:39:19 ru-mail postfix/submission/smtpd[7463]: connect from unknown[45.143.222.192] Jan 1 11:39:19 ru-mail postfix/submission/smtpd[7463]: disconnect from unknown[45.143.222.192] ehlo=1 auth=0/1 rset=0/1 quit=1 commands=2/4
From this ip for example
cat /var/log/mail.log | grep 45.143.222.192 | wc -l 1471 I have fail2ban installed but there is nothing happen with. Okay is connect and disconnect. No error message. I not understand why is so but is ok. Is there a way to cat this mess and write it automated to iptables? Is there other way to catch it with a tool? Would be great have someone an idea here. Thank you Silvio
Le mercredi 1 janvier 2020 10:27:02 CET siefke_listen@web.de a écrit :
I have fail2ban installed but there is nothing happen with. Okay is connect and disconnect. No error message. I not understand why is so but is ok.
Is there a way to cat this mess and write it automated to iptables? Is there other way to catch it with a tool? Would be great have someone an idea here.
As far as I understand, you want to automate blocking IPV4 addresses to access the submission port too often. If you install xtables-addons, this may help : iptables -A INPUT -p tcp -d 587 -i eth0 -m state --state NEW -m recent --name XT_SUB --set iptables -A INPUT -p tcp -d 587 -i eth0 -m state --state NEW -m recent --name XT_SUB --update --seconds 180 --hitcount 5 --rttl -j DROP Adapt -i to your system, and tune --seconds plus --hitcount to your requirements. iptables -m recent --help for more information. It's quite complex. I've got rather good results with this. But you may also block yourself or other legitimate access. This may not fit large professional setups, rather your own postfix instance for personal use. Regards.
Hello, SET via arch-general <arch-general@archlinux.org> wrote:
iptables -A INPUT -p tcp -d 587 -i eth0 -m state --state NEW -m recent --name XT_SUB --set iptables -A INPUT -p tcp -d 587 -i eth0 -m state --state NEW -m recent --name XT_SUB --update --seconds 180 --hitcount 5 --rttl -j DROP
Perfect it seem to work :) Thank you. Silvio
Le mercredi 1 janvier 2020 11:48:20 CET SET via arch-general a écrit :
iptables -A INPUT -p tcp -d 587 -i eth0 -m state --state NEW -m recent --name XT_SUB --set iptables -A INPUT -p tcp -d 587 -i eth0 -m state --state NEW -m recent --name XT_SUB --update --seconds 180 --hitcount 5 --rttl -j DROP
ERRATUM --dport 587 should be used, instead of -d 587 '-d' refers to a host address/mask.
On Wed, Jan 01, 2020 at 10:27:02AM +0100, siefke_listen@web.de wrote:
I have fail2ban installed but there is nothing happen with. Okay is connect and disconnect. No error message. I not understand why is so but is ok.
You need to configure fail2ban. It's more like a framework with lots of builtin but little preconfigured/preenabled stuff. * You need to habe the postfix jail or multiple postfix jails enabled: [postfix] enabled = true [postfix-sasl] enabled = true (...) * You need to ensure that fail2ban actually has logs to work with. For example, if postfix does not write log files but all log output ends up in journald, then you might need to configure fail2ban with the systemd backend to get it to actually consume the logs. [postfix] backend = systemd # or auto (...) * You need to make sure that the regexes actually match messages. That being said, unless you want to do more elaborate evaluation of attempts the iptables-based recent module as already suggested in this thread is the simpler, better solution.
participants (3)
-
lists＠2ion.de
-
SET
-
siefke_listen＠web.de