Обход фильтрации Aladdin eSafe Gateway, когда он используется совместно с Check Point CVP Protocol

 
http://opsec.boom.ru/ru/

В CheckPoint FireWall-1 NG Feature Pack 3 есть достаточно неприятный баг, который проявляется при передачи файлов свыше 2-х мегабайт посредством OPSEC CVP технологии. Выяснения причин дали очень оригинальные результаты.

На наш взгляд межсетевой экран CheckPoint FireWall-1 лучший в своем роде. Специалист может из него выжать многое - от простой блокировки портов до блокирования рекламы с WWW серверов и почты. Перечисление основных вариантов займет целую страницу текста. FireWall-1 предоставляет возможность создавать целую систему безопасности на межсетевом уровне. Можно к нему подключать системы обнаружения атак, системы антивирусного контроля, системы контроля доступа и все это благодаря их же открытому протоколу OPSEC (Open Platform for Secure Enterprise Connectivity). Очень полезная и удобная штука в умелых руках. Однако… техническая поддержка в CheckPoint ни чем не отличается от их FAQ. Т.е. можно считать, что поддержки просто нет. На сложный технический вопрос будет ответ «Вы пробовали включать компьютер в розетку?». Мы, конечно, утрируем, но параллели именно такие. Вот и сейчас попытка решить проблему сродна попытке пробить головой бетонную стену, причем таких ситуаций было много. Только вот известно, что «русские не сдаются», но об этом позже.

С момента выхода апдейта для 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: 1044: 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 и проблему быстренько решат.

С уважением к читателю,
коллектив защитников.