Uffff, mi-ai dat de citit, nu gluma :)
> Ciprian BADESCU wrote:
>> 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.
Sa incerc sa pun problema practic:
Deci un fragment cu offset 0 nu e preluat de regula cu "frag". Si nefiind
un pachet TCP/UDP complet, nici de alte reguli tcp/upd.
Prin urmare ar putea trece de o regula:
$ipfw deny tcp from any to B dst port xxx.
si ar ajunge la
$ipfw allow ip from any to B
deci la destinatie.
Deci ar pune probleme unei politici gen: x servicii interzise, retul permis.
Este vre-o problema pentru politica : y servicii permise, restul interzis
(aduca default deny) ?
>
> 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.
Am sapat un pic prin ipfw, si se pare ca foloseste valoarea din header (pe
un 4.10)
ip.h
u_short ip_off; /* fragment offset field */
ip_fw2.c
/*
* offset The offset of a fragment. offset != 0 means that
* we have a fragment at this offset of an IPv4 packet.
* offset == 0 means that (if this is an IPv4 packet)
* this is the first or only fragment.
*/
offset = ip_off & IP_OFFMASK;
>
> 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
>
__________________________________________________________
Send 'unsubscribe rofug' to [EMAIL PROTECTED] to unsubscribe
