0

I have an ipset named allowList.

I want to allow every connection to my machine on every port but port 80, which there I want to allow connections only to the ipset: allowList.

I want to target only the SYN packets from port 80 for efficiency, so that:

  1. if tcp flag = SYN
  2. if port is 80
  3. if it matches the ipset named allowList

Then allow the connection, otherwise drop the packet (if the packet is SYN 80 and not matched the allowList).

The order is important for efficiency, because I dont want to filter or to slow down an established connection.

I'm trying to write iptables rules for it.

iTaMaR
  • 1
  • Are you having a real case or you just fooling around with theoretical speculations? If you have real case, show us your measurements which show iptables processing is slow (with normal rules, without quirks), while without iptables the processing is blazingly fast. Otherwise your question is off topic on ServerFault, because we talk about real business cases here, not about theoretical speculations. In that case, it will be closed. – Nikita Kipriyanov Oct 20 '21 at 19:14

1 Answers1

0

Such sequential matching is possible to implement using custom chains:

iptables -N c1
iptables -N c2
iptables -A INPUT -p TCP --syn -j c1
iptables -A c1 -p tcp --dport 80 -j c2
iptables -A c2 -m set --match-set allowList src -j ACCEPT
iptables -A c2 -j DROP

However, I doubt you will achieve any noticeable efficiency gain from this. In addition, next admin who'll be in charge of supporting this after you definitely will curse you, at least.

Better don't attempt premature optimization and combine all matches into a single rule. I am sure there are some points in your system which could be optimised with much more noticeable gain.

Nikita Kipriyanov
  • 10,947
  • 2
  • 24
  • 45
  • I'm not using port 80 for `HTTP`, those who connect stays connected and are already on `established` connection, I dont want to make a `look up` for those packets.. – iTaMaR Oct 18 '21 at 20:27
  • Is there any way to achieve it without chaning? will this work: `iptables -A INPUT -p tcp --syn --dport 80 -m set --match-set alowList src -j ACCEPT` `iptables -A INPUT -p tcp --dport 80 -j DROP` – iTaMaR Oct 18 '21 at 20:35
  • 1
    @iTaMaR, have you performed any kind of benchmarking or metric collection to measure the impact of a normal (ie. "I optimized") rule? What kind of factor are we talking? – Ginnungagap Oct 18 '21 at 22:42
  • This kind of rule obviously better, because it is much easier to understand. Manwork is much more costly than computer work. I am not sure if it checks all its modules "in the order", but I think it stops matching once the false condition is met. I.e. it might check port 80 first, or syn first, or even set first, but once something returns "no match" it won't bother checking others. I'd say it again, you are optimizing prematurely and, extremely likely, in the wrong place (as it's always the case with premature optimization). – Nikita Kipriyanov Oct 19 '21 at 06:00
  • @NikitaKipriyanov what if the set contains millions of ip's.. you can't expect the performance to be the same if the the traversal would start from the set matching and fall on the others – iTaMaR Oct 19 '21 at 10:22
  • Set in Linux firewall can contain at most 65536 records. Its performance is independent of how much items are in it, because it is either contigous block of addresses or a hash, i.e. it always has the algorithmic complexty O(1). – Nikita Kipriyanov Oct 19 '21 at 11:24
  • @NikitaKipriyanov it's all about efficiency, whether it "Manwork" or anything else.. right now it's a matter of iptables implementation, order might bring significant improvment in conditions as we see in every programing language, saying that it's not important it's too arrogant.. what if there is billions of ip's in the set and the `rule` could be rejected earlier in a much simpler condition?? – iTaMaR Oct 20 '21 at 18:01
  • @NikitaKipriyanov `set` is a `module` and modules are open and could change their complexity, order could always optimise `rule`! – iTaMaR Oct 20 '21 at 18:04