Ciprian BADESCU wrote:
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) ?
Avand in vedere ceea ce ai gasit tu in sursele ipfw, se pare ca orice pachet IP nefragmentat este tratat ca un fragment cu offset=0, deci nu face obiectul regulei "frag".
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.
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.
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.
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.
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;
-- 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
