Chestia asta ce ai spus-o cu SYN-ul ma pune pe ganduri. E chiar asha periculoasa ? Din man-ul de la ipfw am citit:
frag Matches packets that are fragments and not the first fragment of an IP datagram. Note that these packets will not have the next protocol header (e.g. TCP, UDP) so options that look into these headers cannot match.
Singura metoda concreta de a diferentia corect care este primul fragment dintr-o serie de fragmente ce compun un pachet IP, este ca acesta are headerul de frag_offset setat pe zero, lucru care nu poate fi evitat de catre un atacator. In mod normal, ar trebui sa aiba si MF setat, deci pe 1. Ultimul fragment va avea MF resetat, pe zero.
Deci, determinarea primului fragment din fragmentarea unui pachet IP nu are nici o legatura cu flag-ul de SYN din TCP. SYN e un flag din TCP, iar TCP e un protocol incapsulat de IP. Fragmentarea este un procedeu asigurat de catre protocolul IP.
De ce ipfw refuza fragmente mai mici de 4 bytes (32 de biti)? Pentru ca in primii 32 de biti, in a doua jumatate a lor, se gaseste un camp numit "total length", care trebuie protejat la suprascriere.
Daca cineva este capabil sa suprascrie campul de total length cu pachete fragment ulterioare, are toate sansele sa creeze un "buffer overflow" pe stiva. Un procedeu similar merge impotriva unei masini Windows.
Nu am analizat situatia in cazul IHL.
Am sa redau diagrama IP:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Dupa cum se vede, faptul ca flag-ul "frag" din ipfw nu vede si fragmentele cu offset 0 aparent pune probleme. In realitate aceasta nu inseamna decat ca pentru a porni o fragmentare, nu pot sa trimit de capul meu un pachet cu offset zero, ci trebuie sa determin host-ul destinatie sa cerseasca dupa fragmentare. Acest lucru il pot obtine trimitand pachete mai mari decat se asteapta el. De exemplu peste 576 de octeti.
Exemplu: ma pot conecta la SMTP, dar nu la 22. Ma conectez la SMTP, moment in care in ACL se introduce un keep_state care imi da voie sa continui cu transmisul de pachete. Trimit pachete mari, astfel incat destinatia va cersi fragmentare. In momentul in care cerseste singur dupa fragmentare, in keep_state mi se permite sa-i raspund cu pachete.
Pot trimite chiar si un pachet SYN mare.
Pe de alta parte, daca ACL-ul nu este default to deny, asta inseamna ca nimic nu va opri un fragment cu offset 0.
Oricum, dupa cum se vede si din structura unui pachet IP, nici nu am nevoie sa suprascriu primii 32 de biti din pachet, si nici sa suprascriu incepand de la 0. Este suficient sa suprascriu header-ul in portiunea de fragment_offset si sa pun zero acolo. De aici mai departe, pot suprascrie orice valoare din header-ul protocolului incapsulat, de exemplu din TCP. Cel mai mic pachet SYN TCP are 20 de octeti.
Acesta este si motivul pentru care pf din OpenBSD a preferat sa implementeze procedura de asamblare a pachetelor in mod independent de stiva. Prin scrub, pf are grija sa ia in considerare toate posibilitatile, si sa nu suprascrie fragmente.
Revenind la oile noastre, ce impact are allow frag from any to any? Pai are impactul ca atunci cand se foloseste un firewall cu inspectie de stare, cu keep-state, permite unei persoane din exterior sa trimita fragmente si in afara tabelelor de stare din IPFW.
Sunt unele stive care pot fi pacalite chiar si cu offset-uri negative (redhat < ~6, cu pachete ICMP fragmentate).
In alta ordine de idei, nu stiu cum determina IPFW si nici stiva BSD care este primul fragment. S-ar putea sa ia in calcul doar campul de identificare, care este la discretia expeditorului.
Nota: s-ar putea sa fi facut si afirmatii eronate. Momentan nu imi dau seama. Am sa verific in mod concret pe IPFW si FreeBSD. Trebuie citit codul sursa.
In orice caz, de foarte multe ori o regula speciala pentru "frag" nu este necesara. Poate in cazul aplicatiilor realtime.
Cu stima, -- Alin-Adrian Anton Spintech Systems GPG keyID 0x1E2FFF2E (2963 0C11 1AF1 96F6 0030 6EE9 D323 639D 1E2F FF2E) gpg --keyserver pgp.mit.edu --recv-keys 1E2FFF2E __________________________________________________________ Send 'unsubscribe rofug' to [EMAIL PROTECTED] to unsubscribe
