Weten wat je doet helpt. Als ik bijvoorbeeld de handleiding voor ipfw erbij pak, dan zien ik:
Lijkt me dat je dat redelijk triviaal kan namaken. Verder is het mischien ook leuk om even te vertellen welke filtersoftware we het hier over hebben.

Mijn voorbeeld heeft niet echt betrekking tot specifieke filtersoftware maar op de logica te begrijpen van de TCP implementatie (die vendor afhankelijk blijkt). Een poos geleden heb ik een Cisco compatible extended ACL gemaakt en als alternatief voor established, set ACK gebruikt. Nu blijkt dat daar na verloop van tijd de verbindingen trager worden en/of wegvallen. Dit zou dus kunnen omdat het aantal TCP connecties te hoog oploopt, daar ze niet gesloten kunnen worden in het geval de implementatie voor het sluiten een exclusieve RST vereist.

Hier was ik al bang voor; dit gaat dus niet in een enkele regel. Omdat de ACL uitsluitend een AND (match-all) functie toepast zal [ set ACK AND set RST ] alleen verkeer toelaten waarbij zowel ACK en RST true zijn, terwijl established een OR functie betreft en RST ook zonder ACK toegelaten is.

Dus als ik het goed begrijp is het onderstaande voorbeeld het enige correcte:

allow ip 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.252
deny ip 192.168.2.0 255.255.255.252 192.168.1.0 255.255.255.0 match[all] set SYN [AND] unset URG, ACK, PSH, RST, FIN
allow ip 192.168.2.0 255.255.255.252 192.168.1.0 255.255.255.0 match[all] set ACK
allow ip 192.168.2.0 255.255.255.252 192.168.1.0 255.255.255.0 match[all] set RST

Dat zijn 4 regels voor 1 connectie. Ik vraag me nu af of dat niet efficiënter kan.

Wat probeer je eigenlijk te bereiken? Zijn het squid ACL's?

Overigens werken imho alle firewalls met states, iig iptables en PF, zodat een ACK alleen verzonden kan worden als er bijbehorende SYN packet is geweest.

Handmatig states managen kan wel maar trust me, dat geeft erg veel hoofdpijn. En potentieel gevaarlijk door eenvoudige misconfigs.

Nee het zijn geen squid ACLs maar gegeneraliseerde ACLs. Ik wil goed begrijpen hoe TCP werkt en ook met flags kunnen filteren.

Echter kan ik geen eenduidige informatie vinden: http://www.symantec.com/connect/articles/abnormal-ip-packets vermeld b.v. weer het volgende "Except for the initial SYN packet, every packet in a connection must have the ACK bit set."

Dit is weer tegenstrijdig met "established - Matches TCP packets that have the RST or ACK bits set"

En klopt dat wel? Sommige bronnen spreken b.v. bij een connection teardown met alleen een FIN packet (Wikipedia: "Zodra de verbinding gesloten wordt, stuurt de server of client een pakket met de FIN-vlag, waarna de andere kant antwoordt met een ACK-vlag en dit vervolgens in de omgekeerde richting gebeurt", terwijl andere bronnen dit als een kwaadaardig packet aanmerken (b.v. IDS signatures http://www.juniper.net/techpubs/software/junos-security/junos-security96/junos-security-swconfig-security/id-72577.html).

Blijft vaag dus.

Je zoekt naar de echte protocol specs.
Dan moet je niet naar (nederlandse) wiki pagina's, AV vendor documentatie of dat soort bronnen uit de tweede of derde hand zoeken.
Op z'n best beschrijven die de standaard-alles-ging-goed situatie min of meer juist.

Je kunt dan of de TCP RFC nemen, of een echt grondig naslagwerk zoals
TCP/IP Illustrated (vol 1) van Richard Stevens .

Dan heb je echt een uitgebreide referentie het doorlopen van de protocol state bijbehorend gebruik van vlaggen, met name ook in meer obscure situaties waar je blijkbaar al tegenaan gelopen bent.

Het zou me overigens totaal niet verbazen als IDS signatures (vals) alarm geven op sommige combinaties die ongebruikelijk zijn maar wel technisch correct.

Is niks vaag aan hoor, dit kun je gewoon in een RFC nalezen (RFC 793 is de oer-RFC over TCP).
Waar jij de mist in gaat is dat je denkt dat als er staat "een pakket met FIN vlag" dat betekent "met ALLEEN FIN vlag".
Dat is dus niet zo. De SYN/ACK/FIN/RST vlaggen kunnen ook in bepaalde combinaties voorkomen, het zijn losse bits.

Kijk eens in hoe pf (van OpenBSD) tcp sessies default afhandelt, dan zie je welke flags wanneer gezet zijn. En je ziet welke relevant zijn.

Om er nog even op terug te komen... Ik heb de RFC 793 doorgelezen; indrukwekkende specificatie gezien het bouwjaar 1981 en nog dagelijks het meest gebruikte protocol om betrouwbaar een verzameling bytes van A naar B te krijgen.

Echter door het ontwerp van dit oeroude protocol blijkt de conclusie dat het uitgesloten is dat TCP verkeer goed gereguleerd kan worden d.m.v. alleen inspectie van de vlaggen en poortnummers. De RFC 793 geeft een goede kijk op waarom dat zo is.

Naar wat ik van de specificatie begrepen heb, weegt een foutloze TCP implementatie op host niveau veel zwaarder dan de combinatie van vlaggen in packets die over netwerken reizen. Hoogstens zou men enkele ongeldige combinaties kunnen blokkeren zodat de resultaten van host-os fingerprinting aardig onbetrouwbaar gemaakt kunnen worden. Het blijkt verder erg gemakkelijk een RST 'uit te lokken' bij een host die je wil scannen.

Het klopt ook dat niet alle geldige packets in een established sessie een ACK bevatten. RST kan ook zonder ACK op de packets van een retour connectie enabled zijn en daarmee komt men toch weer op het onderstaande idee uit:

allow ip 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.252
deny ip 192.168.2.0 255.255.255.252 192.168.1.0 255.255.255.0 match[all] set SYN unset ACK
allow ip 192.168.2.0 255.255.255.252 192.168.1.0 255.255.255.0

Echter bij een echte established state wordt er ook gekeken naar sequence- en acknowledgementnumbers.