Сучасні тенденції у галузі контентної фільтрації. Швидкий старт: ICAP-сервер

Адміністрація

Я брав участь у бета-тестуванні icap-демону від Dr.Web, залишився ним задоволений (незважаючи на деякі проблеми, які не вирішені на цей момент), але фінансова сторона питання мене сильно обмежує, тому в черговий раз мій вибір припав на ClamAV.

Використання Squid за допомогою ClamAV та c-icap для перевірки web-трафіку на віруси

Передісторія

Для роботи не знадобиться демон clamd, що працює, так що можете сміливо пропустити його конфігурування (clamd.conf), якщо він не використовується або не буде використовуватися.

c-icap працює зі своїм антивірусним модулем, заснованим на ClamAV, тому нам знадобиться наявність у системі libclamav (досить встановленого звичайним способом ClamAV). У разі відсутності в системі libclamav c-icap просто не збереться.

Встановлення та налаштування c-icap з підтримкою ClamAV

Розпакуємо архів c_icap-220505.tar.gz у /usr/src (або туди, де у вас лежать вихідні коди). Скрипт configure у каталозі з вихідними кодами c-icap слід запускати з наступними параметрами:

$ ./configure --enable-static --with-clamav --prefix=/usr/local/c_icap

Або, наприклад, якщо --prefix=/opt/clamav для configure від ClamAV:

$ ./configure --enable-static --with-clamav=/opt/clamav --prefix=/usr/local/c_icap

Демон c_icap збирається статично. --prefix також можна вказати на смак. Можна збирати і сам демон:

Необхідно перевірити, чи все правильно зібралося:

$ make check

І безпосередньо встановити c-icap в систему (в той каталог, який був вказаний через --prefix):

# make install

Тепер потрібно виправити деякі налаштування в c-icap.conf. У разі нашого --prefix=/usr/local/c_icap не важко здогадатися, що конфіги лежать у /usr/local/c_icap/etc.

• User краще поставити nobody, оскільки wwwrun, вказаний за умовчанням, швидше за все відсутня у системі.
• TmpDir /tmp – ваш каталог тимчасових файлів.
• Далі необхідно налаштувати ACL - Access Control Lists - список IP-адрес, які можуть використовувати даний ICAP-демон: acl localsquid_respmod src 127.0.0.1 type respmod acl localsquid src allow localsquid icap_access deny externalnet

  Так можна визначити, звідки дозволено доступ до нашого сервісу icap, а звідки – ні. Зауважте, що даних ACL визначається не список безпосередніх клієнтів проксі-сервера, саме список клієнтів демона ICAP, тобто. список проксі-серверів (їх IP-адреси).

  Я склав ACL для випадку роботи демона ICAP та Squid на одному хості.

  • srv_clamav.ClamAvTmpDir /tmp – тимчасовий каталог для модуля ClamAV.
  • srv_clamav.VirSaveDir /var/infected/ - каталог карантину. Інші аналогічні краще закоментувати!
  • srv_clamav.VirHTTPServer "DUMMY".

  Можна спробувати і так:
  

  Srv_clamav.VirHTTPServer "http://proxy.your_srv_name.ru/cgi-bin/get_file.pl?usename=%f&remove=1&file="

  Необхідне деяке пояснення: опція srv_clamav.VirSaveDir може бути задана кілька разів - таким чином, що інфіковані файли зберігатимуться в багатьох місцях. Якщо задати одним із карантинних каталогів корінь web-сервера, то можна дати користувачам свідомо скачати інфікований файл. Залишається лише скористатися файлом contrib/get_file.pl у вихідних кодах c-icap.

  У мене потреби в цьому не було.

Створіть каталог /var/infected та зробіть його власником користувача nobody (chown nobody /var/infected).

Здійснимо пробний запуск c-icap:

# cd /usr/local/c_icap/bin # ./c-icap

Якщо повідомлень про помилки немає, варто переконатися і в тому, що c-icap прослуховує потрібний сокет:

# netstat-apn | grep 1344

Якщо бачимо щось схоже на наступний рядок, все гаразд:

Tcp 0 0 *:1344 *:* LISTEN 24302/c-icap

Залишимо демона c-icap працювати і перейдемо до подальших налаштувань.

Встановлення та налаштування проксі-сервера Squid

Розпакуємо в /usr/src отриманий раніше Squid:

# tar zxvf squid-icap-2.5.STABLE11-20050927.tgz

Перейдемо в каталог з вихідними джерелами Squid і запустимо configure так:

$ ./configure --enable-icap-support

До запуску configure у Squid від Dr.Web необхідно запустити bootstrap.sh, що знаходиться у кореневому каталозі вихідних кодів Squid. Якщо ви використовуєте Squid від Dr.Web, обов'язково прочитайте документацію з пакету drweb-icapd!

Збираємо Squid:

Встановлюємо:

# make install

Маємо встановлений Squid у /usr/local/squid. Тепер змінимо налаштування в squid.conf.

Необхідно знайти пару рядків:

#acl our_networks src 192.168.1.0/24 192.168.2.0/24 #http_access allow our_networks

Розкоментувати їх та встановити власне значення, замість 192.168.1.0/24 192.168.2.0/24 (у моєму випадку користувачі проксі-серверs перебували в мережі 172.16.194.0/24):

Acl our_networks src 172.16.194.0/24 http_access allow our_networks

Перейдіть до /usr/local/squid/var, створіть каталог cache. Тепер там виконайте команду:

# chown nobody cache/logs/

Змінити власника необхідно тому, що демон проксі-сервера буде запущений від користувача nobody і не зможе писати логи і використовувати кеш.

Залишилося створити структуру каталогів для кешування. Перейдіть до /usr/local/squid/sbin і виконайте:

# ./squid -z

За замовчуванням параметр cache_dir у squid.conf заданий так:

Cache_dir ufs /usr/local/squid/var/cache 100 16 256

Ви можете змінити шлях до кешу (наприклад, якщо він розташований у вас на іншому розділі або жорсткому диску), і тоді необхідно перевірити права на вказаний каталог.

На цьому етапі ми маємо робочий Squid, але не матимуть підтримки ICAP, тобто. звичайний кешуючий проксі-сервер.

Додамо підтримку ICAP…

Додавання підтримки ICAP у squid.conf

Знайдіть за словом icap_enable і виставте значення icap_enable on. Знайдіть за словом icap_preview_enable і виставте значення icap_preview_enable on. Знайдіть по слову icap_preview_size та виставте значення icap_preview_size 128. Знайдіть за словом icap_send_client_ip та виставте значення icap_send_client_ip on. Знайдіть за словом icap_service і додайте пару таких icap-сервісів:

Icap_service service_avi_req reqmod_precache 0 icap://localhost:1344/srv_clamav icap_service service_avi respmod_precache 1 icap://localhost:1344/srv_clamav

Знайдіть за словом icap_class і додайте такий icap-клас:

Icap_class class_antivirus service_avi service_avi_req

Знайдіть слово icap_access і додайте такі права доступу:

Icap_access class_antivirus allow all

Сумарно для підтримки ICAP у squid.conf мають бути додані наступні рядки:

Icap_enable on icap_preview_enable on icap_preview_size 128 icap_send_client_ip on
icap_service service_avi_req reqmod_precache 0 icap://localhost:1344/srv_clamav icap_service service_avi respmod_precache 1 icap://localhost:1344/srv_clamav
icap_class class_antivirus service_avi service_avi_req icap_access class_antivirus allow all

У цьому мінімальне конфігурування проксі-сервера завершено.

Запустимо його:

# cd /usr/local/squid/sbin # ./squid

Якщо все правильно, то повідомлень у консолі не повинно бути.

Перевірка працездатності

Додайте проксі-сервер у вашому браузері (якщо не прозоре проксіювання) і відкрийте сторінку http://www.eicar.com/anti_virus_test_file.htm .

Спробуйте завантажити файл eicar.com. Якщо ви бачите подібне повідомлення: "A VIRUS FOUND ..." - значить все правильно працює.

Зауважте, що кеш проксі-сервера не повинен містити інфікованих об'єктів! Тому перед початком використання Squid разом із c-icap кеш краще очистити. Також врахуйте, що браузер має власний кеш.

Оновлення антивірусних баз ClamAV

Додати freshclam до crontab. Реініціалізація баз c-icap провадиться кожні srv_clamav.VirUpdateTime хвилин - цей параметр можна вказати в c-icap.conf (за замовчуванням, 15 хвилин).

Файл c-icap.magic та типи об'єктів, що перевіряються.

Цей файл може бути знайдений у тому ж каталозі, що і c-icap.conf. Він є описом форматів різних груп типів файлів (TEXT, DATA, EXECUTABLE, ARCHIVE, GRAPHICS, STREAM, DOCUMENT - певні групи в c-icap.magic за замовчуванням). Антивірусна перевірка будується за типами файлів, що проходять через проски-сервер. Деякі типи, наприклад, можна виключити або додати типи.

Формат запису рядка, для визначення файлу за його magic-числом (послідовністю):

Offset:Magic:Type:Group:Desc

Offset - усунення, з якого починається Magic-послідовність. Type і Group - тип та група, до якої слід відносити файл з даною magic-послідовністю. Desc – короткий опис, технічного навантаження не несе.

Наприклад загляньте в c-icap.magic.

Зверніть увагу, що в c-icap.conf параметр srv_clamav.ScanFileTypes визначає групи і типи файлів (можна прописувати і групи, і типи), які слід перевіряти. Що визначає srv_clamav.VirScanFileTypes, я остаточно не зрозумів, але підозрюю, що групи файлів, що примусово перевіряються (EXECUTABLE і ARCHIVE за замовчуванням).

У моєму конфізі c-icap вищеописані параметри виглядають так:

Srv_clamav.ScanFileTypes TEXT DATA EXECUTABLE ARCHIVE GRAPHICS STREAM DOCUMENT srv_clamav.VirScanFileTypes EXECUTABLE ARCHIVE

Можливі проблеми

• Squid видає повідомлення ICAP protocol error, сторінки не відкриваються. Перевірте, чи вірно ви вказали ACL в c-icap.conf, в цьому ACL повинен бути дозволений доступ не для користувачів, а для проксі-сервера.

  Спробуйте завершити процеси Squid та c-icap, а потім запустити їх у наступному порядку: спочатку c-icap, а потім Squid.

  Також така помилка може виникати, якщо демону с-icap не вистачає прав на запис до карантинного каталогу або в лог-файли.

  Якщо проблема так і не вирішилася, спробуйте запустити Squid з параметрами -d 10 -N -X:

  # ./squid -d 10 -N -X І c-icap з параметрами -N -d 10 -D: # ./c-icap -N -d 10 -D Побачте детальну інформацію, за якою можна розібратися, що і де не так.

• Squid видає повідомлення ICAP protocol error тільки на деяких сторінках (одних і тих же).

  Перевірте, чи є у c-icap права на запис до карантинного каталогу (а ще краще зробити власником усіх карантинних каталогів користувача під яким запущено c-icap).

  Спробуйте запустити c-icap та Squid у режимі налагодження (як це зробити, сказано вище).

  Також непогано подивитися логи c-icap.

  Спробуйте знову завантажити об'єкт, на якому виникає помилка. Можливо, ви дізнаєтеся набагато більше про проблему і зможете її вирішити.

Підсумки

Тепер і web-серфінг захищений від вірусів та інших шкідливих кодів (у тому числі деякі експлоїти для MS IE). Як корпоративне рішення для сервера з великим навантаженням, цей метод не випробуваний, але, думаю, може бути реалізований (хоча б тому, що навантаження можна розподілити на кілька ICAP-серверів). Як рішення для невеликої організації – цілком актуальне.

І пам'ятайте, що розробники пишуть на своєму сайті:

• >The Antivirus ClamAV service
• >Ця служба є під розвиток.

Про деякі принципи роботи протоколу ICAP російською можна дізнатися з керівництва DrWeb-ICAP - одна з успішних комерційних реалізацій протоколу ICAP. Можна прочитати і RFC 3507.

Комфортної та безпечної роботи!

Дякуємо за увагу.

Internet Content Adaptation Protocol (RFC, subject to errata) specifies how HTTP proxy (an ICAP client) може outsource content adaptation to an external ICAP server. Більшість популярних proxies, включаючи Squid, support ICAP. Якщо ваш adaptation algorithm resides в ICAP server, він буде здатний до роботи в різних умовах і не буде depending на одному proxy project або vendor. Відмінні коди змін є необхідними для найбільшого вмісту адаптацій за допомогою ICAP.

Pros: Proxy-independent, adaptation-focused API, Squid modifications, supports remote adaptation servers, scalable. Cons: Communication delays, protocol functionality limitations, needs a stand-alone ICAP server process or box.

Одна програма може бути доступна для багатьох ICAP-серверів, а один ICAP-сервер може бути доступна для багатьох proxies. На ICAP-сервер може залишитися на тій же фізичній машині, як Squid or run on a remote host. Залежно від налаштування і контексту, деякі ICAP failures можуть бутиперевірені, роблячи ними безперервно до proxy end-users.

ICAP Servers

While writing yet інший ICAP server from scratch is always a posability, the following ICAP servers can be modified to support the adaptations you need. Деякі ICAP-сервери навіть пристосовані до adaptation modules or plugins.

Traffic Spicer (C++)

POESIA (Java)

(Java and Javascript)

original reference implementation by Network Appliance.

Такий лист не є сприятливим і не може бути як енергія. У будь-якому ICAP-сервері буде існувати цілий ряд прохів і коней в контексті вашого adaptation project.

Більше інформації про ICAP є доступним на ICAP Forum . While the Forum site not been actively maintained, its members-only newsgroup is still a good place to discuss ICAP issues.

Squid Details

Squid-3.0 and later come with integrated ICAP support. Pre-cache REQMOD і RESPMOD векторні пункти є supported, включно з реакцією satisfaction. Squid-2 має обмежений ICAP support via set of poorly maintained and very buggy patches. Це являє собою worth noting that the Squid developers не longer officially support the Squid-2 ICAP work.

Squid supports receiving 204 (no modification) responses від ICAP servers. Це є типово використовуваним при сервері wants для виконання не modifications на HTTP message. Це useful to save bandwidth by preventing the server from sending the HTTP message back to Squid as it was received. Там є два місцях, де Squid не буде пристосований до 204 response:

• Середня плата loading greater than 64kb.
• Середня плата load cannot be (очевидно)відбувається.

Прикмета для цього є простим: Якщо сервер є відповідь на Squid with 204, Squid потребує maintain на папері оригіналу HTTP message in memory. Ці дві важливі вимоги є основним optimisation до межі Squid's memory usage in supporting 204s.

Squid Configuration

Squid 3.1

Squid-3.1

adaptation_access

adaptation_service_set

icap_client_username_encode

icap_client_username_header

icap_connect_timeout

icap_default_options_ttl

icap_enable

icap_io_timeout

icap_persistent_connections

icap_preview_enable

icap_preview_size

icap_send_client_ip

icap_send_client_username

icap_service

icap_service_failure_limit

icap_service_revival_delay

Squid 3.0

Наступні прикладні інструкції Squid-3.0 до розмови до двох ICAP послуг, один для запиту і один для відповіді adaptation:

Є інші можливості, які можуть контролювати різні аспекти ICAP:

Стартова сторінка модуля

Служба, яка дозволяє клієнтам виконувати непрямі запити до інших мережних служб. Спочатку клієнт підключається до проксі-сервера і запитує будь-який веб-ресурс, розташований на іншому сервері. Потім проксі-сервер або підключається до вказаного сервера і отримує ресурс у нього, або повертає ресурс із власного кешу (якщо хтось із клієнтів вже звертався до цього ресурсу). У деяких випадках запит клієнта або відповідь сервера може бути змінений проксі-сервером у певних цілях.

Також, проксі-сервер дозволяє аналізувати клієнти, що проходять через сервер HTTP-запити, виконувати фільтрацію та облік трафіку по URL і mime-типах. Крім цього, проксі-сервер реалізує механізм доступу в інтернет за логіном/паролем.

Проксі-сервер виконує кешування об'єктів, отриманих користувачами з Інтернету, за рахунок цього скорочує споживання трафіку та збільшує швидкість завантаження сторінок.

При вході в модуль відображається стан служб, кнопка «Вимкнути» (або «Увімкнути», якщо модуль вимкнено) та останні повідомлення в журналі.

Налаштування

Зазвичай для роботи через проксі-сервер, необхідно вказати його адресу та порт у налаштуваннях браузера. Однак, якщо не використовується авторизація користувачів за логіном/паролем, то можна використовувати функцію прозорого проксі.

При цьому всі запити по протоколу HTTP з локальної мережі автоматично надсилаються через проксі-сервер. Таким чином з'являється можливість фільтрації та обліку трафіку URL незалежно від налаштувань клієнтських комп'ютерів.

Порт роботи проксі-сервера за промовчанням 3128, у налаштуванні модуля ви можете змінити його на будь-який вільний порт.

Типи авторизації

Проксі-сервер ІКС підтримує два способи авторизації: за ip-адресою користувача, і за логіном-паролем.

Авторизація за ip-адресою підходить для випадків, коли користувач постійно користується одним і тим же комп'ютером. Проксі визначає, якому користувачеві належить той чи інший трафік, виходячи з IP-адреси його комп'ютера. Цей спосіб не підходить для термінальних серверів, тому що в цьому випадку з однієї IP-адреси працює кілька користувачів. Також цей спосіб не підходить для організацій, де користувачі постійно переміщаються між робочими місцями. Крім того, користувач може змінити IP-адресу свого комп'ютера і, якщо не налаштована прив'язка MAC-адреси до IP, ІКС прийме його за когось іншого.

Авторизація за логіном/паролем вирішує проблему прив'язки користувачів до власного комп'ютера. У цьому випадку, при першому зверненні до будь-якого інтернет-ресурсу, браузер видасть користувачеві запит логіна/паролю для доступу в інтернет. Якщо у вашій мережі користувачі авторизуються в домені, можна встановити тип авторизації «Через домен». У такому випадку, якщо ІКС підключений до контролера домену і з домену були імпортовані користувачі, авторизація буде виконана прозоро, без запиту логіна/паролю.

Крім того, слід пам'ятати, що авторизація на проксі використовується лише для http-трафіку користувачів. Доступ в інтернет для програм, що використовують протоколи, відмінні від http, регулюється міжмережевим екраном, який має лише один спосіб авторизації: за IP-адресою. Іншими словами, якщо користувач використовує лише авторизацію за логіном/паролем, він не зможе користуватися поштою, jabber-клієнтом, torrent-клієнтом та іншими програмами, що не підтримують роботу через http-проксі.

Веб-авторизація

Для того, щоб авторизувати користувачів без прописаного проксі-сервера на ім'я користувача та паролю, ви можете використовувати веб-авторизацію (captive portal), увімкнувши відповідний прапорець. Веб-авторизація дозволяє, наприклад, інтегрувати сторінку авторизації в корпоративний портал і використовувати його як сторінку авторизації. За замовчуванням порту веб-авторизації 82, ви також можете змінити його на будь-який вільний.

Для того, щоб не прописувати вручну проксі-сервер на кожній машині клієнта, ви можете скористатися автоконфігуратором. У браузері клієнта має бути виставлена ​​опція «Автоматична конфігурація проксі», решта всіх параметрів визначить ІКС.

Він включається встановленням прапорця у відповідній вкладці. Можна відзначити один або кілька протоколів з доступних (HTTP, HTTPS, FTP).

Опція публікації скрипта автоналаштування визначає, чи буде він доступний за ip-адресою сервера або за створеним віртуальним хостом з доменним ім'ям. При виборі віртуального хоста він автоматично створиться в системі. Прапорець "Створити запис на ДНС-сервері"автоматично додасть зону із потрібними записами для цього віртуального хоста.

Опублікувати скрипт автоконфігурації з DHCP- цей параметр передає налаштування проксі всім DHCP-клієнтам сервера.

Батьківський проксі

Якщо у вашій організації кілька проксуючих серверів, розташованих ієрархічно, то проксі-сервер, що стоїть для ІКС, буде його батьківським проксі. Крім того, як батьківський проксі може виступати будь-який вузол мережі.

Щоб ІКС перенаправляв запити, що надходять на його проксі-сервер, на батьківський проксі, вкажіть його ip-адресу та порт призначення у вкладці «Батьківський проксі».

Проксі-сервера можуть обмінюватися даними своїх кешів за протоколом ICP. Якщо мережа працює через кілька проксі, це може значно прискорити роботу. Якщо батьківський проксі підтримує роботу протоколу, позначте відповідний прапорець і вкажіть порт служби (за замовчуванням 3130).

Видані ip-адреси

Ця вкладка містить список IP-адрес та користувачів, які авторизувалися на проксі-сервері за допомогою веб-авторизації.

Вміст кешу

У закладці «Журнал» міститься зведення всіх системних повідомлень від проксі-сервера. Журнал розділений на сторінки, кнопками «вперед» і «назад» можна переходити зі сторінки на сторінку, або ввести номер сторінки в поле і перейти відразу на неї.

Записи журналу виділяються кольором залежно від виду повідомлення. Звичайні повідомлення системи позначені білим кольором, повідомлення про стан системи (ввімкнення/вимкнення, обробка кешу) – зеленим, помилки – червоним.

У верхньому правому куті модуля знаходиться рядок пошуку. З її допомогою ви можете шукати у журналі потрібні вам записи.

Журнал завжди відображає події за поточну дату. Щоб переглянути події в інший день, виберіть потрібну дату, використовуючи календар у верхньому лівому куті модуля.

Для коректної інтеграції системи необхідно налаштувати роботу проксі-сервера організації. Загальною вимогою до налаштувань є необхідність налаштування IP-адреси ICAP-сервера SecureTower на проксі-сервері. Для цього ICAP-модуль проксі-сервера повинен бути налаштований таким чином, щоб заголовок запиту, що надсилається ICAP-серверу, включав поле X-Client-IP, що містить IP-адресу користувача. Запити без вказаної IP-адреси будуть прийняті, але не обслуговуватимуться ICAP-сервером.

Серед інших SecureTower підтримує інтеграцію з найпопулярнішими проксі-серверами SQUID та MS Forefront.

SQUID

Система SecureTower підтримує версії SQUID старше 3.0. При установці/компіляції проксі-сервера необхідно активувати опцію включення підтримки ICAP і в налаштуваннях ICAP вказати такі опції:

• icap_enable on
• icap_send_client_ip on - IP-адреса клієнта
• icap_service_req service_reqmod_precache 0 icap://192.168.45.1:1344/reqmod, де 192.168.45.1 - IP-адреса ICAP-сервера SecureTower
• adaptation_access service_req allow all

MS Forefront

Для роботи у мережах, організованих з урахуванням проксі-сервера TMG Forefront, необхідно додатково встановити ICAP-плагин, т.к. за промовчанням ICAP не підтримується цим проксі-сервером. Плагін доступний за посиланням http://www.collectivesoftware.com/solutions/content-filtering/icapclient.

У налаштуваннях ICAP-плагіна потрібно вказати адресу ICAP-сервера SecureTower. В результаті всі дані, передані для протоколу HTTP(S) через проксі-сервер MS Forefront, будуть збережені ICAP-сервером SecureTower.

Мінімальні системні вимоги для ICAP-сервера

• Процесор: 2 ГГц і вище, 2 ядра та більше
• Мережевий адаптер: 100 Мбіт/1 Гбіт
• Оперативна пам'ять: не менше 6 ГБ
• Жорсткий диск: 100 ГБ розділ для операційної системи та файлів SecureTower; другий розділ для зберігання перехоплених даних з розрахунку 1,5 ГБ даних від кожного контрольованого користувача за місяць плюс 3% обсягу перехоплених даних для файлів пошукових індексів
• Windows .Net Framework: 4.7 і вище
• Операційна система: Microsoft Windows Server 2008R2/2012/2016 x64

ICRA (Internet Content Rating Association) - нова ініціатива, що розробляється незалежною некомерційною організацією з тією самою назвою. Основна мета цієї ініціативи – захист дітей від доступу до забороненого вмісту. Ця організація має угоди з безліччю компаній (великі телекомунікаційні та компанії-розробники ПЗ) для забезпечення більш надійного захисту.

ICRA надає програмне забезпечення, яке дозволяє перевіряти спеціальну мітку, що повертається сайтом, та приймати рішення про доступ до цих даних. Програмне забезпечення працює тільки на платформі Microsoft Windows, але завдяки відкритій специфікації існує можливість створення реалізацій ПЗ, що фільтрує, і для інших платформ.

Цілі та завдання, які вирішує ця організація, а також всі необхідні документи можна знайти на сайті ICRA - http://www.icra.org/.

До переваг цього підходу можна віднести те, що для обробки даних потрібно лише спеціальне програмне забезпечення і немає необхідності оновлювати бази адрес та/або категорій, оскільки вся інформація передається самим сайтом. Але недоліком є ​​те, що сайт може вказувати неправильну категорію, що призведе до неправильного надання або заборони доступу до даних. Однак цю проблему можна вирішити (і вона вже вирішується) за рахунок використання засобів підтвердження правильності даних, таких як цифрові підписи тощо.

Фільтрація трафіку у світі Web 2.0

Масове використання про технології Web 2.0 сильно ускладнило контентну фільтрацію веб-трафіку. Оскільки у багатьох випадках дані передаються окремо від оформлення, існує можливість пропуску небажаної інформації користувача або від користувача. У разі роботи з сайтами, що застосовують такі технології, необхідно робити комплексний аналіз даних, що передаються, визначаючи передачу додаткової інформації та враховуючи дані, зібрані на попередніх етапах.

В даний час жодна з компаній, що випускають кошти для контентної фільтрації веб-трафіку, не дозволяє проводити комплексний аналіз даних, які передаються з використанням технологій AJAX.

Інтеграція із зовнішніми системами

У багатьох випадках досить гострим стає питання інтеграції систем контентного аналізу коїться з іншими системами. У цьому системи контентного аналізу можуть бути як клієнтами, і серверами чи обох ролях відразу. Для цього було розроблено кілька стандартних протоколів - Internet Content Adaptation Protocol (ICAP), Open Pluggable Edge Services (OPES). Крім того, деякі виробники створювали власні протоколи для забезпечення взаємодії конкретних продуктів один з одним або стороннім програмним забезпеченням. Сюди можна віднести протоколи Cisco Web Cache Coordination Protocol (WCCP), Check Point Content Vectoring Protocol (CVP) та інші.

Деякі протоколи - ICAP і OPES - розроблені те, що можна використовувати реалізації як сервісів контентної фільтрації, і інших сервісів - перекладачі, розміщення реклами, доставка даних, залежить від політики їхнього поширення, тощо.

Протокол ICAP

В даний час протокол ICAP користується популярністю серед авторів програмного забезпечення для контентної фільтрації та творців програмного забезпечення для визначення шкідливого вмісту (віруси, spyware/malware). Однак варто зазначити, що ICAP в першу чергу розроблявся для роботи з HTTP, що накладає багато обмежень щодо його використання з іншими протоколами.

ICAP прийнятий групою Internet Engineering Task Force (IETF) як стандарт. Сам протокол визначається документом "RFC 3507" із деякими доповненнями, викладеними у документі "ICAP Extensions draft". Ці документи та додаткова інформація доступні з сервера ICAP Forum - http://www.i-cap.org.

Архітектура системи під час використання протоколу ICAP зображено на . Як клієнт ICAP виступає система, через яку передається трафік. Система, що виконує аналіз та обробку даних, називається сервером ICAP. Сервери ICAP можуть у ролі клієнтів інших серверів, що забезпечує можливість стикування кількох сервісів для колективної обробки тих самих даних.

Рисунок 1. Схема взаємодії серверів та клієнтів ICAP

Для взаємодії між клієнтом та сервером використовується протокол, схожий на протокол HTTP версії 1.1, і самі способи кодування інформації. Відповідно до стандарту ICAP може обробляти як вихідний (REQMOD - Request Modification), і вхідний (RESPMOD - Response Modification) трафік. Рішення про те, які з даних будуть оброблятися, приймається клієнтом ICAP, в деяких випадках це унеможливлює повний аналіз даних. Налаштування клієнта повністю залежать від його реалізації, і в багатьох випадках їх неможливо змінити.

Після отримання даних від клієнта сервер ICAP виконує їхню обробку, а якщо це необхідно, то і модифікацію даних. Потім дані повертаються клієнту ICAP, і їх передає далі серверу чи клієнту, залежно від цього, у якому напрямі вони передавалися.

Найбільш широке застосування протоколу ICAP знайшов у продуктах для захисту від шкідливого коду, оскільки він дозволяє використовувати ці перевірки в різних продуктах і не залежить від платформи, на якій виконується клієнт ICAP.

До недоліків використання ICAP можна віднести:

• додаткові мережеві взаємодії між клієнтом та сервером дещо уповільнюють швидкість передачі даних між зовнішніми системами та споживачами інформації;
• існують перевірки, які потрібно виконувати не так на клієнті, але в сервері ICAP, такі як визначення типу даних тощо. Це актуально, оскільки в багатьох випадках клієнти ICAP орієнтуються на розширення файлу або тип даних, повідомлений зовнішнім сервером, що може стати причиною порушення політики безпеки;
• Утруднена інтеграція з системами, що використовують протоколи, відмінні від HTTP, не дозволяє використовувати ICAP для глибокого аналізу даних.

Протокол OPES

На відміну від ICAP, протокол OPES розроблявся з урахуванням особливостей конкретних протоколів. Крім того, при його розробці враховувалися недоліки протоколу ICAP, такі як відсутність автентифікації клієнтів і серверів, відсутність аутентифікації та ін.

Так само як і ICAP, OPES прийнятий групою Internet Engineering Task Force як стандарт. Структура взаємодії сервісів, протокол взаємодії, вимоги до сервісів та рішення щодо забезпечення безпеки сервісів викладено у документах RFC 3752, 3835, 3836, 3837 та інших. Список регулярно поповнюється новими документами, що описують застосування OPES не тільки до обробки інтернет-трафіку, а й до обробки поштового трафіку, а в майбутньому можливо інших видів протоколів.

Структура взаємодії серверів OPES та клієнтів (OPES Processor) зображена на . Загалом вона подібна до схеми взаємодії серверів і клієнтів ICAP, але є і суттєві відмінності:

• є вимоги до реалізації клієнтів OPES, що уможливлює зручніше управління ними - завдання політик фільтрації тощо;
• споживач даних (користувач або інформаційна система) може впливати на обробку даних. Наприклад, при використанні автоматичних перекладачів отримані дані можуть автоматично перекладатися тією мовою, що використовується користувачем;
• системи, що надають дані, також можуть впливати на результати обробки;
• сервери обробки можуть використовувати для аналізу дані, специфічні для протоколу, яким дані були передані клієнту OPES;
• деякі сервери обробки даних можуть отримувати важливіші дані, якщо вони перебувають у довірчих відносинах з клієнтом OPES, споживачами та/або постачальниками інформації.

Рисунок 2. Схема взаємодії клієнтів та серверів OPES

Всі перелічені повноваження залежать тільки від зміни, що застосовується при впровадженні системи. За рахунок цих можливостей використання OPES більш перспективне та зручне, ніж використання протоколу ICAP.

Незабаром очікується поява продуктів, що підтримують OPES нарівні з протоколом ICAP. Піонером у розробці та використанні OPES є компанія Secure Computing зі своєю лінійкою продуктів Webwasher.

Оскільки в даний час немає повноцінних реалізацій, що використовують OPES, то не можна робити остаточні висновки про недоліки даного підходу, хоча теоретично поки що залишається лише один недолік - збільшення часу обробки за рахунок взаємодії між клієнтами та серверами OPES.

HTTPS та інші види шифрованого трафіку

За розрахунками деяких аналітиків, до 50% Інтернет-трафіку передається у зашифрованому вигляді. Проблема контролю шифрованого трафіку зараз є актуальною для багатьох організацій, оскільки користувачі можуть застосовувати шифрацію для створення каналів витоку інформації. Крім того, шифровані канали можуть використовуватися шкідливим кодом для проникнення в комп'ютерні системи.

Існує кілька завдань, пов'язаних із обробкою шифрованого трафіку:

• аналіз даних, що передаються зашифрованими каналами;
• перевірка сертифікатів використовуються серверами для організації шифрованих каналів.

Актуальність цих завдань зростає з кожним днем.

Контроль передачі шифрованих даних

Контроль передачі даних, що пересилаються зашифрованими каналами, є, напевно, найважливішим завданням для організацій, співробітники яких мають доступ до Інтернет-ресурсів. Для реалізації цього контролю існує підхід, який називається "Man-in-the-Middle" (у деяких джерелах його також називають "Main-in-the Middle"), який може використовуватися зловмисниками для перехоплення даних. Схема обробки даних даного методу дана на .

Рисунок 3. Процес обробки шифрованих даних

Процес обробки даних виглядає так:

• в Інтернет-броузер користувача встановлюється спеціально виписаний сертифікат для встановлення з'єднання з проксі-сервером;
• при встановленні з'єднання з проксисервером він використовує відомий сертифікат для розшифровування даних, що передаються;
• розшифровані дані аналізуються так само, як і звичайний HTTP-трафік;
• проксі-сервер встановлює з'єднання з сервером, на який мають бути передані дані, та використовує для шифрування каналу сертифікат сервера;
• дані, що повертаються від сервера, розшифровуються, аналізуються і передаються користувачеві, зашифровані сертифікатом проксі-сервера.

У разі використання цієї схеми обробки шифрованих даних можуть виникати проблеми, пов'язані з підтвердженням істинності користувача. Крім того, потрібне виконання роботи зі встановлення сертифіката в Інтернет-броузері всіх користувачів.

На ринку пропонуються такі продукти контролю передачі шифрованих даних: Webwasher SSL Scanner компанії Secure Computing, Breach View SSL TM , WebCleaner.

Перевірка автентичності сертифікатів

Друге завдання, що виникає під час використання шифрованих каналів передачі, - перевірка справжності сертифікатів, що надаються серверами, з якими працюють користувачі.

Зловмисники можуть здійснювати атаку на інформаційні системи, створюючи помилковий запис в DNS, що перенаправляє запити користувача не на той сайт, який їм необхідний, а на створений самими зловмисниками. За допомогою таких підставних сайтів можуть бути вкрадені важливі дані користувачів, такі як номери кредитних карток, паролі тощо, а також під виглядом оновлень програмного забезпечення може бути завантажений шкідливий код.

Для запобігання подібним випадкам і існує спеціалізоване програмне забезпечення, яке виконує перевірку відповідності сертифікатів, наданих сервером, тим даними, про які вони повідомляють.

У разі розбіжності, система може заблокувати доступ до таких сайтів або здійснити доступ після явного підтвердження користувачем. Обробка даних при цьому виконується практично тим же способом, що і при аналізі даних, що передаються шифрованими каналами, тільки в цьому випадку аналізуються не дані, а сертифікат, що надається сервером.

Фільтрування поштового трафіку

При використанні електронної пошти організації стикаються з необхідністю забезпечення захисту як для вхідного, так і для вихідного трафіку. Але завдання, розв'язувані кожному за напрямів, досить сильно різняться. Для вхідного трафіку необхідно забезпечити контроль шкідливого коду, фішингу та небажаної пошти (спаму), тоді як у вихідній пошті контролюється вміст, передача якого може призвести до витоку важливої ​​інформації, поширення компрометуючих матеріалів тощо.

Більшість продуктів, що існують на ринку, надають контроль лише вхідного трафіку. Це здійснюється за рахунок інтеграції з антивірусними системами, реалізації різних механізмів захисту від небажаної пошти та фішингу. Багато з цих функцій вже вбудовуються в поштові клієнти, але вирішити завдання вони не можуть.

Захист від фішингу найчастіше здійснюється шляхом порівняння одержуваних поштових повідомлень з наявною базою адрес сайтів та повідомлень. Такі бази надаються постачальниками програмного забезпечення.

Для захисту користувачів від спаму в даний час існує декілька способів:

• порівняння отримуваних повідомлень з наявною базою повідомлень. При порівнянні можуть застосовуватися різні методики, включаючи використання генетичних алгоритмів, які дають змогу вичленувати ключові слова навіть у разі їх спотворення;
• динамічна категоризація повідомлень з їхнього вмісту. Дозволяє дуже ефективно визначати наявність небажаної кореспонденції. Для протидії цьому методу розповсюджувачі спаму використовують розсилку повідомлень у вигляді зображення з текстом усередині та/або набори слів зі словників, які створюють шум, що заважає роботі даних систем. Однак у майбутньому можливі антиспамові системи, здатні розпізнавати текст усередині зображень і таким чином визначати їхній вміст;
• сірі, білі та чорні списки доступу дозволяють описувати політику отримання поштових повідомлень з відомих або невідомих сайтів. Застосування сірих списків у багатьох випадках допомагає запобігти передачі небажаних повідомлень за рахунок специфіки роботи ПЗ, що розсилає спам. Для чорних списків доступу можуть використовуватися як локальні бази даних, керовані адміністратором, так і глобальні, що поповнюються на основі повідомлень користувачів з усього світу. Однак використання глобальних баз даних загрожує тим, що в них можуть потрапити цілі мережі, у тому числі й "хороші" поштові сервери, що містять.

Для боротьби з витоками інформації використовуються різні способи, засновані на перехопленні і глибокому аналізі повідомлень відповідно до складної політики фільтрації. У цьому випадку виникає необхідність коректного визначення типів файлів, мов і кодувань текстів, проведення семантичного аналізу повідомлень, що передаються.

Ще одне із застосувань систем для фільтрації поштового трафіку - створення шифрованих потоків пошти, коли система автоматично підписує або шифрує повідомлення, а на іншому кінці з'єднання здійснюється автоматичне розшифрування даних. Цей функціонал дуже зручний, якщо ви хочете обробляти всю вихідну пошту, але вона має доходити до адресата у зашифрованому вигляді.

Фільтрування миттєвих повідомлень

Засоби передачі миттєвих повідомлень (Instant messaging) поступово переходять у розряд інструментів, що активно використовуються в багатьох компаніях. Вони забезпечують швидку взаємодію з співробітниками та/або клієнтами організацій. Тому цілком закономірно, що розвиток засобів, які, крім іншого, можуть виявитися і каналом для витоку інформації, призвело до появи інструментів для контролю інформації, що передається.

В даний час для обміну миттєвими повідомленнями найбільше часто використовуються протоколи MSN (Microsoft Network), AIM (AOL Instant Messaging), Yahoo! Chat, Jabber та їх корпоративні аналоги – протоколи Microsoft Live Communication Server (LCS), IBM SameTime та Yahoo Corporate Messaging Server. На території СНД широкого поширення набула система ICQ, яка зараз належить компанії AOL і використовує практично такий самий протокол, як і AIM. Всі зазначені системи виконують практично одне й те саме - передають повідомлення (як через сервер, так і безпосередньо) та файли.

Тепер майже у всіх систем з'явилися можливості для дзвінків з комп'ютера на комп'ютер і/або на звичайні телефони, що створює певні труднощі для систем контролю і вимагає підтримки VoIP для реалізації повноцінних проксі-серверів.

Зазвичай продукти для контролю IM-трафіку реалізуються як прикладний шлюз, що виконує розбір даних і блокує передачу заборонених даних. Проте є і у вигляді спеціалізованих серверів IM, які здійснюють необхідні перевірки лише на рівні сервера.

Найбільш потрібні функції продуктів для контролю IM-трафіку:

• керування доступом за окремими протоколами;
• контроль клієнтів тощо;
• контроль доступу окремих користувачів:
  • дозвіл користувачеві спілкування лише в межах компанії;
  • дозвіл користувачеві спілкування лише з певними користувачами поза компанією;
• контроль текстів, що передаються;
• контроль передачі файлів Об'єктами контролю є:
  • розмір файла;
  • тип та/або розширення файлу;
• напрямок передачі даних;
• контроль наявності шкідливого вмісту;
• визначення SPIM;
• збереження переданих даних для подальшого аналізу.

Нині контроль над передачею миттєвих повідомлень дозволяють виконувати такі продукты:

• CipherTrust IronIM компанії Secure Computing. Цей продукт має підтримку протоколів AIM, MSN, Yahoo! Chat, Microsoft LCS та IBM SameTime. Зараз це одне з найповніших рішень;
• IM Manager компанії Symantec (розроблений компанією IMLogic, яка була поглинена Symantec). Цей продукт має підтримку наступних протоколів – Microsoft LCS, AIM, MSN, IBM SameTime, ICQ та Yahoo! Chat;
• Antigen for Instant Messaging компанії Microsoft також дозволяє працювати практично з усіма популярними протоколами передачі миттєвих повідомлень;
• Webwasher Instant Message Filter, компанії Secure Computing.

Продукти інших компаній (ScanSafe, ContentKeeper) мають менші можливості порівняно з перерахованими вище. Варто зазначити, що дві російські компанії - "Гран Прі" (продукт "SL-ICQ") та "Мера.ру" (продукт "Сормович") - надають продукти для контролю над передачею повідомлень з використанням протоколу ICQ.

Фільтрування VoIP

Зростання популярності засобів передачі звукової інформації між комп'ютерами (званих також Voice over IP (VoIP)) змушує вживати заходів до контролю передачі такої інформації. Є різні реалізації для дзвінків із комп'ютера на комп'ютер та/або на звичайні телефони.

Існують стандартизовані протоколи для обміну такою інформацією, сюди можна віднести Session Instatiation Protocol (SIP), прийнятий IETF та H.323, розроблений ITU. Ці протоколи є відкритими, що уможливлює їх обробку.

Крім того, існують протоколи, розроблені конкретними компаніями, які не мають відкритої документації, що ускладнює роботу з ними. Однією з найпопулярніших реалізацій є Skype, який завоював широку популярність у всьому світі. Ця система дозволяє виконувати дзвінки між комп'ютерами, робити дзвінки на стаціонарні та мобільні телефони, а також приймати дзвінки зі стаціонарних та мобільних телефонів. В останніх версіях підтримується можливість обміну відео.

Більшість наявних на даний момент продуктів можна поділити на дві категорії:

• продукти, які дозволяють визначити та блокувати VoIP-трафік;
• продукти, які можуть визначити, захопити та проаналізувати VoIP-трафік.

• продукти компанії "Dolphian", що дозволяють визначити та дозволити або заборонити VoIP-трафік (SIP та Skype), який інкапсульований у стандартний HTTP-трафік;
• продукти компанії Verso Technologies;
• різні види міжмережевих екранів, що мають таку можливість.

• продукт російської компанії "Сормович" підтримує захоплення, аналіз та збереження голосової інформації, яка передається за протоколами H.323 та SIP;
• бібліотека з відкритим кодом Oreka () дозволяє визначити сигнальну складову звукового трафіку і виконати захоплення даних, які потім можна проаналізувати іншими засобами;
• Нещодавно стало відомо, що розроблений фірмою ERA IT Solutions AG продукт дозволяє перехоплювати VoIP-трафік, що передається за допомогою програми Skype. Але для такого контролю необхідно встановити спеціалізований клієнт на комп'ютер, на якому працює Skype.

Фільтрування peer-to-peer

Використання співробітниками різних peer-to-peer (p2p) мереж несе такі загрози для організацій:

• поширення шкідливого коду;
• витік інформації;
• поширення даних, захищених авторським правом, що може призвести до судового переслідування;
• зниження продуктивність праці;

Існує велика кількість мереж, що працюють у форматі peer-to-peer. Існують мережі, що мають центральні сервери, які використовуються для координації користувачів, а є мережі повністю децентралізовані. У другому випадку їх особливо важко контролювати за допомогою таких стандартних засобів, як міжмережні екрани.

Для вирішення цієї проблеми багато фірм створюють продукти, що дозволяють детектувати та обробляти p2p-трафік. Для обробки p2p-трафіку існують такі рішення:

• SurfControl Instant Messaging Filter, який обробляє p2p нарівні з обробкою миттєвих повідомлень;
• пакет Websense Enterprise також надає користувачам засоби контролю p2p-трафіку;
• Webwasher Instant Message Filter дозволяє контролювати доступ до різних p2p-мереж.

Використання цих або інших, не перерахованих тут продуктів різко скорочує ризики, пов'язані з доступом користувачів до p2p-мереж.

Unified Threat Management

Рішення, які відповідають концепції Unified Threat Management, пропонуються багатьма виробниками засобів захисту. Як правило, вони побудовані на базі міжмережевих екранів, які, крім основних функцій, виконують ще й функції контентної фільтрації даних. Як правило, ці функції зосереджені на запобіганні вторгненням, проникненню шкідливого коду та небажаних повідомлень.

Багато таких продуктів реалізуються у вигляді апаратно-програмних рішень, які не можуть повністю замінити рішення для фільтрації поштового та інтернет-трафіку, оскільки працюють лише з обмеженою кількістю можливостей, що надаються конкретними протоколами. Зазвичай їх використовують для того, щоб уникнути дублювання функцій у різних продуктах, і для забезпечення гарантій, що всі прикладні протоколи будуть оброблятись відповідно до однієї бази відомих загроз.

Найбільш популярними рішеннями концепції Unified Threat Management є такі продукти:

• SonicWall Gateway Anti-Virus, Anti-Spyware та Intrusion Prevention Service забезпечує антивірусний та інший захист даних, що передаються за протоколами SMTP, POP3, IMAP, HTTP, FTP, NetBIOS, протоколами Instant Messaging та багатьма потоковими протоколами, що застосовуються для передачі аудіо- та відеоінформації ;
• серія пристроїв ISS Proventia Network Multi-Function Security, виконаних у вигляді програмно-апаратних комплексів, забезпечує блокування шкідливого коду, небажаних повідомлень та вторгнень. У постачання включено велику кількість перевірок (у тому числі і для VoIP), які можуть бути розширені користувачем;
• апаратна платформа Network Gateway Security компанії Secure Computing, крім захисту від шкідливого коду та небажаних повідомлень, також має підтримку VPN. У складі цієї платформи об'єднано практично всі рішення Secure Computing.

Існують інші продукти, але перелічені вище мають масове поширення.

Перехоплення даних

Перехоплення даних (Lawful interception) практично завжди використовувався спецслужбами для збору та аналізу інформації, що передається. Однак останнім часом питання перехоплення даних (не тільки Інтернет-трафіку, а й телефонії та інших видів) стало дуже актуальним у світлі боротьби з тероризмом. Навіть ті держави, які завжди були проти таких систем, почали використовувати їх для контролю над передачею інформації.

Оскільки перехоплюються різні види даних, що часто передаються високошвидкісними каналами, то для реалізації таких систем необхідне спеціалізоване програмне забезпечення для захоплення і розбору даних і окреме програмне забезпечення для аналізу зібраних даних. Як таке може використовуватися для контентної фільтрації того чи іншого протоколу.

Мабуть найвідомішою з таких систем є англо-американська система Echelon, яка довго використовувалася для перехоплення даних на користь різних відомств США та Англії.

Серед російських продуктів можна згадати рішення від компанії "Сормович", що дозволяє захоплювати та аналізувати поштовий, звуковий та Інтернет-трафік.

Продукти компанії "Інфосистеми Джет"

"Інфосистеми Джет" працюють на ринку контентної фільтрації вже понад шість років. Початок було покладено системою для фільтрації поштового трафіку, потім розробки перейшли до інших областей застосування контентної фільтрації, і компанія не збирається зупинятися на досягнутому.

В останні півроку відбулося кілька подій, пов'язаних із продуктами контентної фільтрації, які випускає компанія. Йдеться про вихід четвертої версії системи моніторингу та архівування поштових повідомлень (СМАП) "Дозор-Джет" та початок розробки другої версії системи контролю веб-трафіку (СКВТ) "Дозор-Джет". Обидва продукти мають багато відмінностей та нововведень у порівнянні з попередніми версіями.

Крім названих продуктів у компанії розроблено інше програмне забезпечення, також пов'язане з проблемами контентної фільтрації, - бібліотеки визначення типів даних та модуля визначення типів та розпакування даних для Lotus/Cerberus.

СМАП "Дозор-Джет"

Отже, у четвертій версії СМАП "Дозор-Джет" реалізовано нові можливості, що забезпечують вищий рівень фільтрації поштових потоків. Зміни, що торкнулися системи, можна розділити на кілька розділів:

• загальні зміни;
• зміни у підсистемі фільтрації;
• зміни у підсистемі управління;
• зміни у модулях розширення.

Деякі зміни кардинально відрізняють цей продукт від тих, що пропонують інші компанії. Про це буде розказано у відповідних розділах.

Перехід на нову версію здійснюється без втрати напрацьованих політик фільтрації – для цього розроблені засоби міграції даних та документація щодо їх використання.

Додаткову інформацію про СМАП "Дозор-Джет" можна знайти на продуктовому сайті компанії "Інфосистеми Джет": http://www.jetsoft.ru/ або з інших випусків бюлетеня Jet Info, електронна версія: .

Загальні зміни

До загальних змін відносяться такі, які торкаються всіх частин системи, наприклад:

• підтримка Unicode - всі частини системи використовують Unicode як внутрішній кодування даних. Ця зміна дозволяє використовувати систему в багатомовних середовищах і підтримувати різні мови як для обробки листів, так і для інтерфейсу користувача. Є можливість миттєвого перемикання мови підсистеми керування. На даний момент для неї реалізована підтримка російської, англійської та японської мов;
• перероблено схему бази даних, що дозволило підвищити швидкість закладки повідомлень в архів та прискорити пошук по архіву;
• надсилання повідомлень виділено в окрему підсистему, це підвищило надійність обробки повідомлень та спростило інтеграцію із зовнішніми поштовими системами;
• у постачанні системи тепер йдуть типові політики, в яких знаходяться найчастіше використовувані умови, позначки та інші об'єкти політики фільтрації;
• як бази даних використовуються Oracle 10g і PostgreSQL 8.x, що дозволило збільшити обсяги зберігання без істотної зміни вимог до серверів баз даних. Крім того, в даний час ведеться робота над модулем взаємодії з Microsoft SQL Server для підприємств, на яких не використовується СУБД Oracle.

Ці зміни суттєво вплинули на архітектуру системи та дозволили виключити більшу частину обмежень та недоліків, що існували у попередніх версіях.

Зміни у підсистемі фільтрації

Зміни в підсистемі фільтрації вплинули на продуктивність системи. До них можна віднести:

• новий парсер листів реалізує механізми "ледачого" розпакування листів та об'єктів. Цей механізм суттєво підвищує продуктивність, оскільки розпакування листа та об'єктів, що його складають, проводиться тільки в тому випадку, коли є відповідна умова (перевірка типу файлу, наявність тексту у файлі, наявність помилок розпакування).
• Нова система визначення типів дозволяє дуже точно визначати типи даних, що передаються, і вибирати відповідні обробники.
• Нова система визначення мов та кодувань коректно визначає кодування та мову текстових об'єктів і перетворює їх у внутрішнє уявлення підсистеми фільтрації – Unicode.
• У новій версії позначки прив'язуються не до листа, як це було раніше, а до об'єктів листа, що дозволяє створювати складніші політики фільтрації, наприклад, чи всі файли зашифровані, або визначати, який файл викликав помилку розпакування.
• У підсистемі фільтрації з'явилися нові умови фільтрації:
  • умова для перевірки часу доби - уможливлює реалізацію відкладеної доставки повідомлень, для деяких їх видів, наприклад, що містять файли з аудіо- та відеоінформацією;
  • Умова перевірки дня тижня може використовуватися виявлення незвичайної активності в неробочі дні.
• Також було реалізовано і нові дії:
  • відкладена доставка листів - зазвичай використовується разом з іншими умовами, такими як розмір листа або час відправлення, та забезпечує надсилання листів після вказаного часу;
  • пріоритетна доставка листів забезпечує прискорену доставку деяких видів листів.
• Нові розпакувальники та конвертери:
  • додано підтримку архівів 7zip, deb, rpm і cpio;
  • додано аналізатор текстових файлів, який дозволяє виділити з тексту бінарні дані закодовані за допомогою base64, uuencode та quoted-printable. Ця утиліта коректно обробляє неправильно пересилаються листи (forwarded) і ті випадки, коли користувачі намагаються закодувати дані для обману системи, що пересилаються;
  • коректно обробляються файли, rar, приєднані до інших типів файлів - MS Word, tiff, jpeg та інші;
  • зроблено вилучення текстових коментарів із усіх типів архівів та файлів mp3.
• Антивірусна підтримка тепер реалізується лише за допомогою протоколу ICAP, що дозволяє використовувати наступні антивіруси: Symantec, Trendmicro, DrWeb, Clamav (за допомогою програми c-icap), Kaspersky ICAP Server та інші, що мають підтримку ICAP.
• З'явилася можливість підключення модулів попередньої обробки повідомлень і тепер для обробки повідомлень можна застосовувати антиспамові системи сторонніх виробників.

Зміни у підсистемі управління

Інтерфейс управління системою зазнав кардинальних змін. Він отримав новий дизайн, для його реалізації використано технологію Ajax, що збільшило швидкість відгуку на дії користувача системи. Загальний вигляд нового інтерфейсу користувача представлено на .

Рисунок 4. Загальний вигляд інтерфейсу користувача системи

СКВТ "Дозор-Джет"

Система контролю веб-трафіку (СКВТ) "Дозор-Джет" - порівняно новий продукт компанії, але вже добре себе зарекомендував у користувачів. З моменту його випуску минуло півтора роки, зараз ведеться активна розробка другої версії СКВТ "Дозор-Джет". У ній заплановані такі зміни:

• кардинально перероблений інтерфейс користувача:
  • для прискорення роботи користувачів застосовується технологія Ajax, інтерфейс стає більш схожим на інтерфейс 4-ї версії СМАП "Дозор-Джет";
  • інтерфейс користувача підтримує роботу з різними мовами - зараз це російська, англійська та японська;
  • керування допоміжними утилітами (вивантаження даних з бази, резервне копіювання тощо) здійснюється через веб-інтерфейс з можливістю налаштування роботи за розкладом.
• У підсистемі фільтрації:
  • додано фільтрацію за будь-яким із заголовків запитів або відповідей;
  • додано фільтрацію за командами протоколу HTTP;
  • користувач може бути автентифікований за декількома ознаками - ім'я/пароль, IP-адреса, MAC-адреса;
  • Для встановлення категорії сайту використовуються як зовнішні бази категорій сайтів, так і семантичний аналіз вмісту сайтів. Система підтримує роботу з базами категорій сайтів від компаній NetStar та ISS/Cobion;
  • реалізовано підтримку протоколу ICAP для взаємодії з антивірусним програмним забезпеченням;
  • для аналізу тексту у вихідних документах можна використовувати зовнішні конвертери;
  • реалізовано оповіщення адміністратора під час спрацьовування заданих умов;
  • POST-запити можуть зберігатися до бази даних і можуть бути проаналізовані пізніше.
• Сильно перероблено підсистему звітності:
  • додано нові типові звіти - Top-N користувачів з трафіку, Top-N найбільш відвідуваних сайтів, Top-N форматів файлів, що найбільш активно використовуються, та інші;
  • реалізовано можливість автоматичної генерації звітів за розкладом;
  • виведення результатів у різні формати - HTML з картинками, PDF, CSV.

Друга версія СКВТ "Дозор-Джет" планується до випуску на російський ринок у першому кварталі 2007 року.

Міжмережевий екран Z-2

Міжмережевий екран Z-2 можна зарахувати до засобів, що реалізують концепцію UTM. Система має у своєму складі базові засоби контентної фільтрації даних, що передаються, включаючи їх антивірусну перевірку для всіх протоколів, для яких існують аналізатори протоколів.

У новій версії реалізована антивірусна перевірка даних через ICAP в шлюзах HTTP, FTP, SMTP і POP3, що дозволяє легко інтегруватися з рядом популярних AV-рішень.

Для шлюзу SMTP протоколу реалізовано підтримку протоколу SPF та механізму сірих списків доступу (graylisting). У поєднанні з іншими можливостями обробки SMTP потоку це дозволяє значно скоротити кількість небажаних листів до їх обробки засобами контентної фільтрації, знижуючи навантаження на них.

Як додаткові можливості можна виділити обмеження смуги пропускання залежно від типу вмісту в HTTP-шлюзі.

Система визначення типів

Визначення типів даних відіграє важливу роль розробки продуктів контентної фільтрації. Багато компаній використовують для цієї мети широко поширену утиліту file, добре відому користувачам UNIX-подібних операційних систем. Однак у цієї утиліти є численні недоліки, які призводять до частих помилок у визначенні типів. Тому компанією розроблено власну систему визначення типів, що дозволяє зробити цю операцію дуже точною.

Нова система визначення типів даних має такі можливості:

• Спеціалізована мова опису перевірок типів даних дозволяє реалізувати дуже складні перевірки. Це повноцінна мова програмування з наступними можливостями:
  • підтримуються типи даних: числа (big & little endian), рядки, символи, списки;
  • підтримка багатьох операцій - порівняння, арифметичні, бітові, логічні;
  • підтримується пряма і непряма адресація даних, що перевіряється, що дозволяє аналізувати інформацію, ґрунтуючись на інформації, ліченій на попередніх етапах аналізу;
  • підтримка умовних операторів дозволяє зробити умови більш гнучкими;
  • форматований висновок дозволяє керувати виводом результатів;
  • можливість розширення мови перевірок дозволяє проаналізувати дуже складні структури.
• Можливе підключення додаткових модулів аналізу. На даний момент існують такі додаткові модулі аналізу:
  • модуль визначення типів для OLE-файлів – Microsoft Visio, Project, Word, Excel, PowerPoint;
  • модуль визначення тексту та методів його кодування;
  • модуль визначення файлів, що виконуються MS-DOS (.com-файли).
• Явне відображення сигнатур у mime-типи дозволяє уникнути дублювання інформації (що є у стандартній утиліті file).

Модуль визначення типів та розпакування даних для Lotus/Cerberus

Цей модуль є доповненням до програмного забезпечення Cerberus для Lotus Domino, яке виконує функції аналізу повідомлень, що передаються в рамках роботи системи Lotus Domino. Однак ця система володіє малими можливостями з аналізу типів даних, що передаються. Для її вирішення і розроблено цей модуль.

Модуль дозволяє виконувати такі завдання:

• вести список дозволених та заборонених типів даних;
• для дозволених типів даних можна вказати додаткову команду обробки даного типу файлів, наприклад, розпакувати архів або витягти текст із файлів Microsoft Word.

Функціонує модуль під управлінням операційної системи Microsoft Windows і зараз успішно застосовується в одному з найбільших російських банків.

Висновок

Розвиток інформаційних систем призводить до виникнення нових і нових загроз. Тому розвиток продуктів контентної фільтрації не тільки не відстає, але іноді навіть і передбачає виникнення нових загроз, зменшуючи ризики для інформаційних систем, що захищаються.