Score:0

Allow only SYN packets to port 80 matching an ipset

in flag

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.

Nikita Kipriyanov avatar
za flag
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.
Score:0
za flag

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.

iTaMaR avatar
in flag
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 avatar
in flag
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`
Ginnungagap avatar
gu flag
@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?
Nikita Kipriyanov avatar
za flag
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).
iTaMaR avatar
in flag
@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
Nikita Kipriyanov avatar
za flag
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).
iTaMaR avatar
in flag
@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 avatar
in flag
@NikitaKipriyanov `set` is a `module` and modules are open and could change their complexity, order could always optimise `rule`!
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.