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. -- Kerin Millar
