On 2/24/2023 11:10 AM, Kerin Millar wrote:
On Fri, 24 Feb 2023 10:38:43 -0800
Gordon Fisher <gordfisherman@xxxxxxxxx> wrote:
On 2/23/2023 6:15 AM, Kerin Millar wrote:
On Thu, 23 Feb 2023 13:50:33 +0100
Fourhundred Thecat <400thecat@xxxxxx> wrote:
> On 2023-02-23 12:34, Kerin Millar wrote:
On Thu, 23 Feb 2023 12:04:44 +0100
Fourhundred Thecat <400thecat@xxxxxx> wrote:
The following option is detailed by iptables-extensions(8).
--exist
when adding an entry if it already exists, reset the timeout
value to the specified one or to the default from the set defi‐
nition
OK, thank you. But now I have this problem:
I want to:
1) reset timeout if IP alredy in PORTSCAN
2) drop the packet
I wrote these 2 rules:
1) -A INPUT -j SET --add-set PORTSCAN src --timeout 3600 --exist
2) -A INPUT -m set --match-set PORTSCAN src -j DROP
but the problem is, rule 1) matches everything, not just IPs already in
PORTSCAN. This basically adds everything to PORTSCAN
How can I combine these two rules into one, so that I only reset IPs
that are already in PORTSCAN ?
Given the constraints imposed by iptables, the problem needs to be reasoned with in a different fashion. I think that the following will satisfy your requirements.
-N reset_and_drop
-A reset_and_drop -j SET --add-set PORTSCAN src --timeout 3600 --exist
-A reset_and_drop -j DROP
-A INPUT -m set --match-set PORTSCAN src -j reset_and_drop
...
-A INPUT -p tcp -m tcp --dport 22222 -j ACCEPT
...
-A INPUT -m addrtype --src-type UNICAST -j reset_and_drop
Out of curiosity, why is that last line (explicitly setting addrtype [to
UNICAST]) needed? I had long understood that that was effectively the
default already?
It isn't setting the address type. Rather, it's checking whether the type of the source address is UNICAST as a condition for adding to the set. My reasoning is that the OP has not otherwise limited the scope of the rule in question and that it would be undesirable to potentially add addresses that fall into the categories of BROADCAST, MULTICAST, UNREACHABLE, LOCAL or whatever else. The latter category would be particularly unfortunate as it covers all addresses that are assigned to any of the links that the host owns. The OP is unlikely to want to have the capability for the host to effectively ban itself in production.
I see that I misread that rule. Thank you very much for the
clarification. Yes, LOCAL would be particularly unwanted there.
--
gordonfish
