Just wondering what the best rule order is for established connections in the forward chain. Should it come first because the highest traffic rules should be processed first (keeping logic intact) to keep CPU cost down? Or should it come after some other rules in order to boost security (if there is such a tradeoff)?
It’s my highest traffic rule and currently rule number 63, my last processed rule.
I can see an argument that it should come first because if a connection is established it’s already made it’s way through the rules in order to become established, so why keep filtering each packet and spending CPU for no reason? On the other hand I’m not sure if each packet should be filtered through a higher number of rules for some security reason.
I took over this role recently and have to learn the networking side more thoroughly, I’ve searched the forum for answers before posting this but wasn’t able to find anything concrete. The wiki describes creating the established rule but doesn’t say where the priority should be with regard to other Accept rules.
Typically, you do want that first or at least as early as possible for the very reason you’re thinking.
If you have some filters that you would like to be able to use to cut off existing flows, you can place those in the prerouting chain of the RAW table, which happens before state tracking. The raw table is a good place to put a rule blocking traffic to/from an IP blacklist (if you make an address-list for blacklisted IPs and check this in the raw table, then even established/related connections will get filtered)
So in your opinion I won’t be opening us up to some wicked vulnerability by upping the priority for the “established” rule? The only blacklist rules I see presently are the recommended port-scanner ones.
Just wondering if there is more in depth discussion about this anywhere, it seems like a very practical question everyone has to tackle but the only “best practice” I’ve seen suggested is “higher traffic rules be processed first while keeping logic intact”?
established = state tracking has seen traffic in both directions.
related = state tracking helper has noticed that the packet is part of a connection negotiated in another established connection
No packet will match these states as part of an initial connection, so the packet will go past this rule and be compared against the other rules. If some rule accepts the packet, then the subsequent packets in the connection will match this rule. Essentially, what this rule means is “I have already approved this packet.” The main drawback to having it first is as I stated earlier: it doesn’t allow you to revoke permission on established sessions, because the state tracking engine doesn’t do all that - it just knows the connection is established already, and if the firewall rules start with “accept such packets” then removing a host from a permission list in some later rule will not break any existing connections.
This is how my port knocking routines work, by the way. The successful knock only allows new connections from the remote host for 60 seconds, but once established, the session can stay up for as long as required. If I close the connection or get disconnected for some reason after 60 seconds, then I’d have to knock again before being able to establish a new session.
Best example of related:
MT router listens in on ftp-control channel, and notices an active ftp download is about to take place, and opens the required ftp-data port (=related) automatically.
Yeah - but I think “established” is what catches these. Essentially, the state tracking flags the socket as “established” as soon as it sees the reply packet, prior to the packet being sent to the firewall chains for processing. At least that’s my understanding. So by the time the filter rule gets a look at the packet, the tracking has seen packets in both directions, albeit quite recently in the reply direction.
Related also seems to be what allows things like ICMP unreachable messages to UDP socket requests, TTL expired, etc.
