On 13-10-21 11:50 AM, Tom Eastep wrote: > > Try this: > > /etc/shorewall/actions > > ban > fail2ban > > /etc/shorewall/action.fail2ban > ban - - > > /etc/shorewall/action.ban is empty > > /etc/shorewall/rules > > ?section ESTABLISHED > > fail2ban net all > > ?section NEW > > fail2ban net all
I have noted later in the thread to use ipsets and this is a good idea, indeed. but before we add another complication I just wanted to report that this is not quite working. I think I know why. Here's the net2loc chain for example: Chain net2loc (1 references) pkts bytes target prot opt in out source destination 528K 175M fail2ban all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate ESTABLISHED 528K 175M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate ESTABLISHED 7984 752K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED 7340 967K fail2ban all -- * * 0.0.0.0/0 0.0.0.0/0 The problem as you can see is that while this does route established sessions through the [fail2]ban chain[s] as desired it's also not allowing a new outbound session to get ESTABLISHed to a host that's in the ban chains, I believe because the SYN-ACK from the remote (to which we are trying to ESTABLISH a connection to) that is needed to get the connection into the ESTABLISHed state is being sent to the ban chains by the 4th rule. Thoughts? Cheers, b.
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
_______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
