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
                      \_______________________________________________

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Reply via email to