Security Professionals
- ipfw add deny all from eindgebruikers to any
TCP Flags in een ACL gebruiken
06-03-2014, 17:19 door Anoniem, 8 reacties
Ik vroeg mij af wat de beste cq veiligste methode was om TCP connecties directioneel te maken met behulp van TCP flags (urg, ack, psh, rst, syn en fin), zonder de connecties te laten sneuvelen.
Het gaat om een simpele ACL welke door middel van een AND functie op de TCP vlaggen, pakketten kan filteren.
Een manier is bijvoorbeeld:
allow ip 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.252
allow ip 192.168.2.0 255.255.255.252 192.168.1.0 255.255.255.0 match[all] set ACK
Verkeer kan dan alleen retour als de ACK vlag van alle pakketten TRUE is; een connection kan vanuit 192.168.2.0 niet gemaakt worden naar 192.168.1.0 omdat dit alleen kan met een pakket met uitsluitend de SYN flag als TRUE.
Echter het kan ook op de volgende manier
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
Dit maakt de ACL echter anderhalf keer zo groot, wat bij een flinke ACL minder overzichtelijk wordt, maar is wel de meest nette oplossing.
Een combinatie zou ook kunnen, mits dit de connectie niet kapot zal maken.
In diverse bronnen word hiervoor normaal de established functie gebruikt, maar deze is in mijn geval niet beschikbaar.
Welke methode is nu het meest 'correct' ?
Het gaat om een simpele ACL welke door middel van een AND functie op de TCP vlaggen, pakketten kan filteren.
Een manier is bijvoorbeeld:
allow ip 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.252
allow ip 192.168.2.0 255.255.255.252 192.168.1.0 255.255.255.0 match[all] set ACK
Verkeer kan dan alleen retour als de ACK vlag van alle pakketten TRUE is; een connection kan vanuit 192.168.2.0 niet gemaakt worden naar 192.168.1.0 omdat dit alleen kan met een pakket met uitsluitend de SYN flag als TRUE.
Echter het kan ook op de volgende manier
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
Dit maakt de ACL echter anderhalf keer zo groot, wat bij een flinke ACL minder overzichtelijk wordt, maar is wel de meest nette oplossing.
Een combinatie zou ook kunnen, mits dit de connectie niet kapot zal maken.
In diverse bronnen word hiervoor normaal de established functie gebruikt, maar deze is in mijn geval niet beschikbaar.
Welke methode is nu het meest 'correct' ?
Reacties (8)
Weten wat je doet helpt. Als ik bijvoorbeeld de handleiding voor ipfw erbij pak, dan zien ik:
established
Matches TCP packets that have the RST or ACK bits set.
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.Matches TCP packets that have the RST or ACK bits set.
Door Anoniem: Weten wat je doet helpt. Als ik bijvoorbeeld de handleiding voor ipfw erbij pak, dan zien ik:
established
Matches TCP packets that have the RST or ACK bits set.
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.Matches TCP packets that have the RST or ACK bits set.
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.
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.
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.
Door Anoniem: 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.
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.
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.
19-03-2014, 20:04 door
ej__
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.
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.
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
