În pachetul FeaturePoint FireWall-1 NG Feature Pack 3 există o problemă destul de neplăcută care se manifestă atunci când se transferă fișiere de peste 2 megaocteți prin intermediul tehnologiei OPSEC CVP. Explicarea motivelor a dat rezultate foarte originale.
Odată cu lansarea update pentru CheckPoint FireWall-1 NG, care poartă numele mândru de Feature Pack 3 (ceva de genul servive Pack) nu mai treacă prin firewall-ul fișiere groase, dacă utilizați scanarea anti-virus. HTTP, SMTP, date FTP, dar dacă acestea nu depășesc 2 megabytes. Apelul în sprijinul CheckPoint nu a oferit nimic, cu excepția durerii de cap în redactarea descrierilor problemei în cazul unei reduceri de presiune diferite. Răspunsul este unul: "dar totul funcționează pentru noi". Au început să păcătuiască pe antivirusul lor și să încerce să conecteze alte antivirusuri. Și un miracol! Un anti-virus, și de la același producător țară FireWall numit eSafe Gateway, funcționează „Ura!“. Totul trece, totul este verificat. Este păcat că diagnosticul evenimentelor este slab, dar puteți trăi cu el. Este posibil, dar temporar ... Au început să sapă mai adânc. Am început să ne uităm la traficul dintre FireWall și eSafe. Apoi am avut un accident vascular cerebral, iar părul se afla la capăt, când au înțeles ce face eSafe. eSafe Gateway verifică aproximativ primele 15 kilobiți de date primite de la FireWall și numai pe baza acestor date oferă diagnostice! La început nu ne-am putut crede ochii. A început să verifice prin trimiterea virusului prin poștă. Dacă virusul este la începutul literei, atunci este determinat. Dacă este mai mult decât aceste 15 kilobiți, atunci eSafe nu o vede! Apoi am fost vizitați de o idee strălucită de a privi setările eSafe. Au privit. Nu ați găsit nimic în care puteți seta cantitatea de date care trebuie verificată. Ok. Să nu fie eSafe un antivirus, ci doar un fals pentru el. Exit a decis să caute prin crearea propriului anti-virus. S-au găsit biblioteci și documentația OPSEC. Spre bucuria noastră OpsecSdkNgFp3.WIN32.tar.gz arhiva conține un exemplu de exact ceea ce ne-am dorit să creeze. cvp_av_server.c - este un exemplu de simplu Server`a OPSEC CVP (CVP - Conținut Protocol Vectoring), care are totul, cu excepția testului pentru virusul. Compilate, lansate și ... au căzut pe aceeași rake. Un fișier de 2.7 megabytes expediat prin FireWall nu a reușit. În sine, ei au trimis aceste informații în sprijin. Și sprijinul în sine nu vrea să audă despre asta. Rândul turnicilor avem, dar într-un mod foarte politicos! Tastați "am verificat, dar problema dvs. nu este respectată." Dar ce au verificat acolo? Același eSafe, sau ce? Apăsați și va fi capabil de a păcăli, dar să se gândească ... Nu este clar de ce este imposibil de a utiliza propriul exemplu (cvp_av_server.c) pentru a verifica propria lor FireWall. De-a lungul timpului, sa constatat că patch-urile se fac rapid numai pentru clienții mari. Cu o mizerie, ca noi, nu transpirați.
Din punct de vedere tehnic, bug-ul arată astfel.
1. FireWall acceptă datele SMTP, o plasează într-un fișier de director de tip spool și o transmite către serverul CVP pentru verificare, dar în porțiuni.
2. Transmisia se oprește temporar după una sau două megabiți (am observat numai aceste două limitări).
3. Exact (!) În 5 minute transferul către serverul CVP continuă (numărul acestor porțiuni poate fi mai mare).
4. După CVP Server a primit date și a declarat că FireWall, firewall-ul se schimbă imediat la fișierul mosor de bobina \ d_resend (directorul pentru a trimite mai târziu). În jurnal (SmartView Tracker), această operație nu este reflectată în nici un fel.
După expirarea timpului specificat în setările FireWall, acest fișier încearcă să trimită în conformitate cu schema de mai sus. Ie Până când fișierul este distrus, este prea vechi. Puteți observa această problemă în fișierul MDQ.LOG dacă activați depanarea din linia de comandă
"Fw debug mdq pe MDQ_DEBUG_LEVEL 3".
Iată o bucată din jurnalul MDQ.ELG pentru elementul 4:
[Skip]
[mdq 1008] @firewall fwav_send: sesiunea 12bd440 buf = 012199D8, len = 1247
[mdq 1008] @firewall fwav_send: sesiunea 12bd440 buf = 0012EC90, len = 5
[mdq 1008] @firewall fwav_send: sesiunea 12bd440 buf = 00000000, len = 0
// Toate, sfârșitul datelor trimise către serverul CVP
// Serverul CVP a luat cele mai recente date, raportate de FW.
// FW, dintr-un motiv oarecare, pune imediat aceste date în D_resend.
fwav_sdk_dummy_handler: conexiunea este activă
[mdq 1008] @firewall INFO NU este tratată în new_av_client: get_reply
// Cine ar explica ce este "INFO NU este manipulat ..."
[mdq 1008] @firewall fwav_accept_data: sesiunea 12bd440
[mdq 1008] @firewall fwasync_connbuf_realloc: realocarea 1203150 de la 1036 la 5
[mdq 1008] @firewall fwasync_connbuf_realloc: realocarea 11ab7d0 de la 1053 la 5
[mdq 1008] @firewall fwasync_mux_out: 920: write: conexiunea Resetați de peer
[mdq 1008] @firewall fwav_drop: sesiunea 12bd440
[mdq 1008] @firewall eliminați sesiunea din tabelul uid!
[mdq 1008] @firewall sesiune opac NULL
[mdq 1008] @firewall fwasync_mux_in: 1044: citiți: Conectare Resetare de peer
[mdq 1008] @firewall mdq_scan: scanarea directorului mdq
[mdq 1008] @firewall mdq_scan: scanarea directorului mdq
[mdq 1008] @firewall mdq_scan: scanarea directorului mdq
[Skip]
Fie că este vorba de un bug, sau de FireWall care așteaptă o comandă / semnal de la serverul CVP, pe care au uitat să o descrie în exemplul respectiv, nu a fost posibil să aflăm.
Deci, trimiteți viruși misters, trimiteți! Numai ei nu ar trebui să fie primii, dar kilobyte edak prin 20 de la începutul scrisorii. Poate că ne-am dor de acest pahar de nefericire, dar va ajunge ceva "grosier" pentru CheckPoint și rezolva rapid problema.
În ceea ce privește cititorul,
echipa de apărători.
Articole similare
Trimiteți-le prietenilor: