On 9/12/2017 10:19 AM, Phil Stracchino wrote:
> This is semi-hypothetical ...
> 
> I often see spews of failed connect attempts logged by postscreen:
> 
> Sep 12 11:13:09 minbar postfix/postscreen[9238]: CONNECT from
> [70.39.115.203]:54708 to [10.24.32.15]:25
> Sep 12 11:13:09 minbar postfix/postscreen[9238]: PREGREET 14 after 0.12
> from [70.39.115.203]:54708: EHLO ylmf-pc\r\n
> Sep 12 11:13:10 minbar postfix/postscreen[9238]: HANGUP after 0.24 from
> [70.39.115.203]:54708 in tests after SMTP handshake
> Sep 12 11:13:10 minbar postfix/postscreen[9238]: DISCONNECT
> [70.39.115.203]:54708
> Sep 12 11:13:10 minbar postfix/postscreen[9238]: CONNECT from
> [70.39.115.203]:54865 to [10.24.32.15]:25
> Sep 12 11:13:10 minbar postfix/postscreen[9238]: PREGREET 14 after 0.12
> from [70.39.115.203]:54865: EHLO ylmf-pc\r\n
> Sep 12 11:13:10 minbar postfix/postscreen[9238]: HANGUP after 0.24 from
> [70.39.115.203]:54865 in tests after SMTP handshake
> Sep 12 11:13:10 minbar postfix/postscreen[9238]: DISCONNECT
> [70.39.115.203]:54865
> 
> and so on.  It would be nice to be able to automatically block these IPs
> temporarily, and that's what fail2ban does.  However, I think fail2ban
> makes the assumption that the firewall in use is iptables and that it's
> running on the same host.  My firewall is in front of all the internal
> servers, and runs shorewall as a front-end to iptables.
> 
> Has anyone set up fail2ban to trigger from postscreen rejections and
> apply blocks to a firewall on a separate host?  And if so, any tips to
> share?
> 
> 
> 


Tip #1: Ignore these.  The log entries are annoying, but other than
logs this causes pretty close to zero impact on your system.

Tip #2: If you just can't make yourself look away, remember that
fail2ban can run any script when it triggers. Can you script updates
to the external firewall?  Put that in fail2ban as the action.
(although remote control of firewall settings sounds like a
generally bad idea unless implemented very carefully)

Tip #3: It will probably be easier to activate the firewall on your
mail server and block connections locally rather than controlling an
external firewall.

Tip #4: Just ignore the log entries.  The same IP probably goes away
fairly soon, so blocking the IP probably doesn't do much good.



  -- Noel Jones

Reply via email to