У CheckPoint FireWall-1 NG Feature Pack 3 є досить неприємний баг, який проявляється при передачі файлів понад 2-х мегабайт за допомогою OPSEC CVP технології. З'ясування причин дали дуже оригінальні результати.
З моменту виходу апдейта для CheckPoint FireWall-1 NG, який носить горде ім'я Feature Pack 3 (щось на зразок Servive Pack) перестали проходити товсті файли через FireWall, якщо використовувати антивірусну перевірку. HTTP, SMTP, FTP дані проходять, але якщо вони не більше 2-х мегабайт. Звернення на підтримку CheckPoint нічого не дало, крім головного болю по складанню описів проблеми під різним ракурсом. Відповідь одна: «а у нас все працює». Стали грішити на свій антивірус і пробувати підключати інші антивіруси. І диво! Один антивірус, причому з тієї ж країни виробника FireWall, під назвою eSafe Gateway, працює «на ура!». Все проходить, все перевіряється. Шкода, що діагностика подій у нього слабка, але з цим жити можна. Можна, але тимчасово ... Стали копати глибше. Почали дивитися трафік між FireWall і eSafe. Тут нас стався напад, причому волосся стало дибки, коли зрозуміли що саме робить eSafe. eSafe Gateway перевіряє приблизно перші 15 кілобайт отриманих даних з FireWall і на основі тільки цих даних дає діагностику! Ми спочатку не повірили своїм очам. Стали перевіряти, посилаючи вірус поштою. Якщо вірус на початку листа, то він визначається. Якщо він знаходиться далі цих 15-й кілобайт, то eSafe його не бачить! Тут нас відвідала геніальна думка подивитися настройки eSafe. Подивилися. Чи не знайшли нічого, де можна встановити обсяг перевірених даних. Ok. Нехай eSafe НЕ антивірус, а всього лише підробка під нього. Вихід вирішили шукати шляхом створення власного а-ля антивіруса. Знайшли бібліотеки та документацію OPSEC. До нашої радості архів OpsecSdkNgFp3.WIN32.tar.gz містить в собі приклад саме того, що ми хотіли створити. cvp_av_server.c - це приклад простого OPSEC CVP Server`а (CVP - Content Vectoring Protocol), в якому є все, крім самої перевірки на вірус. Відкомпільоване, запустили і ... натрапили на ті ж граблі. Файл в 2.7 мегабайта, надісланий поштою, через FireWall не пройшов. Само собою відправили цю інформацію в підтримку. І само собою підтримка вже чути про це не хоче. Відкоша ми отримали, але в дуже ввічливій формі! Типу «ми перевірили, але Ваша проблема у нас не спостерігається». А ось чим там перевіряли? Тим же eSafe, чи що? Натиснути кнопку і дурень зможе, а ось подумати ... Абсолютно не зрозуміло, чому не можна використовувати власний приклад (cvp_av_server.c) для перевірки власного FireWall. Згодом з'ясували, що патчі там швидко роблять тільки для великих клієнтів. З дрібницею, типу нас, не возяться.
Технічно баг виглядає наступним чином.
1. FireWall приймає SMTP дані, кладе це в файл директорії spool і переправляє їх на CVP Server для перевірки, але порціями.
2. Передача тимчасово зупиняється через один або через два мегабайти (ми помітили тільки ці два обмеження).
3. Рівне (!) Через 5 хвилин передача на CVP Server триває (кількість цих порцій може бути кілька).
4. Після того, як CVP Server прийняв дані і сказав про це FireWall, цей FireWall тут же перекладає файл з spool в spool \ d_resend (в директорію для посилки пізніше). У журналі (SmartView Tracker) ця операція ніяк не відображена.
З плином часу, зазначеного в налаштуваннях FireWall цей файл намагається відправити за вищеописаною схемою. Тобто до тих пір, поки файл не буде знищений, як занадто старий. Можна спостерігати цю проблему в файлі MDQ.LOG, якщо включити налагодження з командного рядка
«Fw debug mdq on MDQ_DEBUG_LEVEL 3».
Наведемо шматок балки MDQ.ELG за пунктом 4:
[Skip]
[Mdq 1008] @firewall fwav_send: session 12bd440 buf = 012199D8, len = 1247
[Mdq 1008] @firewall fwav_send: session 12bd440 buf = 0012EC90, len = 5
[Mdq 1008] @firewall fwav_send: session 12bd440 buf = 00000000, len = 0
// Все, кінець даних, переданих на CVP Server
// CVP Server прийняв останні дані, про що і повідомив FW.
// FW, чомусь, тут же поклав ці дані в D_resend.
fwav_sdk_dummy_handler: connection is active
[Mdq 1008] @firewall INFO is NOT handled in new_av_client: get_reply
// Хто б пояснив, що тут є `INFO is NOT handled ...`
[Mdq 1008] @firewall fwav_accept_data: session 12bd440
[Mdq 1008] @firewall fwasync_connbuf_realloc: reallocating 1203150 from 1036 to 5
[Mdq 1008] @firewall fwasync_connbuf_realloc: reallocating 11ab7d0 from 1053 to 5
[Mdq 1008] @firewall fwasync_mux_out: 920: write: Connection Reset by peer
[Mdq 1008] @firewall fwav_drop: session 12bd440
[Mdq 1008] @firewall remove session from uid table!
[Mdq 1008] @firewall session opaque NULL
[Mdq 1008] @firewall fwasync_mux_in: тисяча сорок чотири: read: Connection Reset by peer
[Mdq 1008] @firewall mdq_scan: scanning the mdq dir
[Mdq 1008] @firewall mdq_scan: scanning the mdq dir
[Mdq 1008] @firewall mdq_scan: scanning the mdq dir
[Skip]
Чи то це баг, чи то FireWall чекає якусь команду / сигнал від CVP Server`а, яку забули описати в прикладі, - з'ясувати не вдалося.
Так, що шліть панове віруси, шліть! Тільки вони повинні бути не першими, а кілобайт десь через 20 від початку листа. Може нас обмине ця чаша біди, але на неї попадеться який-небудь «крупняка» для CheckPoint і проблему швиденько вирішать.
З повагою до читача,
колектив захисників.