On 4/12/19 11:07 AM, Vieri Di Paola wrote: > On Fri, Apr 12, 2019 at 2:56 AM Tom Eastep <teas...@shorewall.net> wrote: >> >> On 4/11/19 3:16 PM, Tom Eastep wrote: >>> On 4/10/19 7:24 PM, Vieri Di Paola wrote: >>>> On Wed, Apr 10, 2019 at 9:45 PM Tom Eastep <teas...@shorewall.net> wrote: >>>>>> ADD(POL_BL:src):info:polbl,add2polbl >>>>>> net1,net2,net3:!+POL_BL,+GLOBAL_WL,+NORMAL_WL all tcp,udp - >>>>>> !+POL_BL_EXCL >>>>>> >>>>> >>>>> That is a good solution. Another would be to create an action with >>>>> multiple leading CONTINUE rules (that together specify the ports that >>>>> you want to exclude) followed by an ADD rule. >>>> >>>> Unfortunately, I cannot use an ipset for that because I get an error: >>>> >>>> ERROR: Invalid/Unknown tcp port/service (+POL_BL_EXCL) >>> >>> Ah yes -- I failed to notice that you want to exclude based on the >>> source port (why do you want to do that?) >>> >> >> But if that is really what you want to do, here is a patch that corrects >> handling of an ipset in the SOURCE PORT(S) column. >> >> patch path/to/Chains.pm < SRCPORTSET.patch > > I can confirm that the patch works as I expect it to. > > I exclude based on the source IP address to avoid false positives in > the following logic in my rules file: > Almost at the top of the file I DROP connections from net* hosts with > src IP addresses in the POL_BL ipset. > Then follow ACCEPT / DNAT rules all along the file until I at the very > bottom I ADD(src) to POL_BL. However, I want to avoid doing so if the > source port is known valid traffic originating from within my lans > (HTTP, HTTPS, etc).
Does that actually match any traffic? The reason that I ask is that if the packet is part of an existing connection, it will be ACCEPTED by a earlier rule that matches conntrack state ESTABLISHED. > The end result is that external hosts truly trying > to access "unauthorized" ports are banned for a given time lapse. > At the very top of the rules file I also do a REDIRECT for those host > connections whose IP addresses are in POL_BL and are trying to access > port 80. They are sent to another HTTP port serving an info page > informing them of why they are blocked (that is, if they ever try to > connect to port 80 after they were banned trying to access an > unauthorized port). > That's also why I don't use the Shorewall built-in blacklist feature > (REDIRECT). I think you could still use the BLACKLIST feature if you redirected traffic to port 80 if the source IP was in the Shorewall blacklist ipset. -Tom -- Tom Eastep \ Q: What do you get when you cross a mobster with Shoreline, \ an international standard? Washington, USA \ A: Someone who makes you an offer you can't http://shorewall.org \ understand \_______________________________________________
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users