> Asadar in cazul unei politici y servicii permise, restul interzis, se
> pot trimite pachete cu MF setat si offset=0 (deci more fragments to
> come, first fragment) catre orice destinatie ce este permisa de ACL.
OK
>
> Cu alte cuvinte: accepti pachete SYN catre portul 80. Ok. Deci pot
> trimite un first-fragment catre portul 80. Daca faci keep-state si NU ai
> regula cu "frag", fragmentele ulterioare pe care incerc sa le trimit
> catre acelasi port NU vor fi permise.
>
> Ideea e ca e imposibil sa faci un firewall care face keep-state pe
> fragmente, decat daca faci ceea ce a facut scrub pentru pf: reasamblezi
> tot separat si independent. IPFW nu face asta.
Asa e :(
ip_fw2.c:
case O_FRAG:
match = (hlen > 0 && offset != 0);
break;
*
* Iar primul fragment este verificat asftel
*
case O_IP_SRCPORT:
case O_IP_DSTPORT:
/*
* offset == 0 && proto != 0 is enough
* to guarantee that we have an IPv4
* packet with port info.
*/
if ((proto==IPPROTO_UDP || proto==IPPROTO_TCP)
&& offset == 0) {
u_int16_t x =
(cmd->opcode == O_IP_SRCPORT) ?
src_port : dst_port ;
u_int16_t *p =
((ipfw_insn_u16 *)cmd)->ports;
int i;
for (i = cmdlen - 1; !match && i>0;
i--, p += 2)
match = (x>=p[0] && x<=p[1]);
}
break;
>
> Asadar, keep-state face ca orice fragment (cu offset > 0) de orice
> natura, legitima sau nu, sa fie dropped.
>
> Daca tu insa adaugi regula cu "frag", schimbi acest consens, si
> determini firewall-ul ca sa accepte orice fragment.
>
> Iata cum reactioneaza IPFW pe un 4.10 cand ai ACL cu keep-state si
> incerci sa trimiti fragmente care sa faca bypass (pe porturi deschise):
>
> Jun 14 16:31:22 cp /kernel: ipfw: -1 Refuse TCP X.X.X.X:43038
> 216.240.143.74:80 in via xl0 (frag 49618:[EMAIL PROTECTED])
> Jun 14 16:31:22 cp /kernel: ipfw: -1 Refuse TCP X.X.X.X:43038
> 216.240.143.74:443 in via xl0 (frag 18944:[EMAIL PROTECTED])
> Jun 14 16:31:22 cp /kernel: ipfw: -1 Refuse TCP X.X.X.X:43038
> 216.240.143.74:21 in via xl0 (frag 23809:[EMAIL PROTECTED])
> Jun 14 16:31:22 cp /kernel: ipfw: -1 Refuse TCP X.X.X.X:43039
> 216.240.143.74:80 in via xl0 (frag 17925:[EMAIL PROTECTED])
> Jun 14 16:31:22 cp /kernel: ipfw: -1 Refuse TCP X.X.X.X:43039
>
> Daca insa as fi avut si regula cu "frag", fragmentele ulterioare ar fi
> ajuns in stiva fara probleme.
>
> Q: se pot face suprascrieri de fragmente pe stiva pe portul 80 daca
> portul 80 este permis de ACL cu keep-state?
> A: nu. Se poate trimite doar un singur fragment, primul. Restul vor fi
> dropped.
>
> Q: daca se permite portul 80 cu keep-state, si exista regula cu frag, se
> poate conecta cineva la un port nepermis?
> A: da, dar numai indirect, prin suprascrierea primului fragment.
Dimensiunea minima a unui fragment este de 8 octeti(date) + header. Adica
din primii 8 octeti TCP ar ajunge in primul fragment IP portul
sursa+destinatie (plus sequence number). Porturile TCP ar trebui
verificate fie de regula check-state, fie de regula de setup ce face
keep-state.
Daca schimb portul, la un pachet cu offset 0 nu ar fi acceptat de regula
check-state, nici de regula frag.
Daca schimb portul la un pachet cu offset != 0, TCP-ul de la host-ul
destinatie ar trebui sa observe problema la reasamblare, si sa ceara
retransmisia (pachetului TCP).
Prin urmare nu imi dau seama cum s-ar putea schimba portul?
Scuze daca e cumva evident, dar nu am experienta in TCP/IP.
>
> Q: daca se permite portul 80 fara keep-state, si NU exista regula cu
> frag, se poate conecta cineva la un port nepermis?
> A: da, prin suprascrierea primului fragment.
>
> Observatie: IPFW are doua moduri de functionare:
>
> 1) daca exista cel putin un keyword keep-state sau checkstate, va
> functiona ca firewall cu stare de inspectie (dinamic)
> 2) daca nu exista unul din cele doua keywords, va functiona ca un
> firewall static
>
> In modul de functionare 1), fragmentele sunt parte din regula default,
> care poate fi deny sau open, exceptand cazul in care se foloseste regula
> "allow frag from any to any".
>
> In modul de functionare 2), fragmentele sunt permise, exceptand cazul in
> care se foloseste regula "deny frag from any to any" sau cand este
> "default to deny".
>
> Concluzie: in mod normal, daca nu se permit fragmente in mod explicit,
> intr-o politica "default to deny" ipfw nu poate fi pacalit cu fragmente.
>
> Introducerea unei reguli care sa de-a voie fragmentelor introduce riscul
> ca un programator care stie ce face sa "pacaleasca" IPFW. In fond IPFW
> nu face decat sa respecte ACL-ul furnizat.
>
__________________________________________________________
Send 'unsubscribe rofug' to [EMAIL PROTECTED] to unsubscribe
