Администрирование системы FraudWall реализовано через WWW-интерфейс.

Рисунок 1. Модуль FraudWall. Интерфейс системы

При работе в демонстрационном режиме установка каких-либо других модулей либо компонент системы не требуется - WWW-интерфейс представляет собой набор статических файлов, которые могут быть записаны, например, на CD-диск, и запущены непосредственно с CD-диска без какой-либо установки на компьютер.

В режиме работы с реальными данными необходима установка дополнительных модулей системы FraudWall на сервер. Демонстрационный режим может быть запущен даже в том случае, если возможна работа с реальными данными (например, для обучения сотрудников бэк-офиса работе на новой системе).

Выбор режима работы осуществляется в процессе аутентификации пользователя:

Рисунок 2. Выбор режима работы в процессе аутентификации пользователя

WWW-интерфейс содержит в себе встроенную помощь, которая доступна при клике мышкой на значок

Рисунок 3. Встроенная помощь в WWW-интерфейсе системы

В системе предусмотрены информационные сообщения-подсказки, улучшающие работу пользователя в системе:

Рисунок 4. Подсказки в WWW-интерфейсе системы

В качестве одного из источников получения данных о действиях клиента система FraudWall использует HTTP-трафик между клиентом банка и сервером системы ДБО.

Помимо получения дампа HTTP-трафика, FraudWall позволяет фильтровать HTTP-трафик, поступающий из сети Интернет, блокируя попадание вредоносных либо нежелательных запросов непосредственно на WWW-сервер банка (т.е. фактически, является Web Application FireWall).

hGuard представляет собой модуль FraudWall, реализовывающий весь вышеперечисленный функционал.

Схематически работа модуля hGuard показана ниже на рисунках.

Рисунок 5. Схема функционирования модуля hGuard (работа в режиме прокси)

Рисунок 6. Схема функционирования модуля hGuard (генерация содержимого непосредственно на сервере Apache)

На рисунке показаны:

Таблица 2. Условное обозначение

Обозначение	Функционал
	(Используется при необходимости) Организовывает шифрованное HTTPS-соединение между клиентом и сервером Apache
	Собственно модуль hGuard - проверяет входящий трафик от клиента на допустимость (защищая тем самым сервер ДБО от несанкционированного доступа) и сохраняет дамп трафика (от клиента к WWW-серверу и обратно) в файл
	(Используется при необходимости) Кеширует трафик WWW-сервера (если страница находится в кеше, содержимое отдается непосредственно из кеша)
	(Используется при необходимости) Пробрасывает HTTP-запрос, полученный от клиента, на другой WWW-сервер. Дополнительно осуществляется балансировка нагрузки между WWW-серверами (если их несколько)
	Станицы сайта, непосредственно располагающиеся на сервере Apache
	Компоненты, необходимые для работы модуля BSI системы BS-Client на сервере Apache

Защита системы ДБО от мошеннических платежей, созданных злоумышленником от имени клиента, реализуется с помощью модуля анализатора трафика.

Данный модуль осуществляет анализ дамп-файла, сформированного модулем фильтрации HTTP-трафика, на предмет обнаружения подозрительных платежей в системе ДБО.

В процессе своей работы модуль анализатора трафика формирует для каждого клиента банка статистический профиль, который храниться в базе данных системы. Статистический профиль клиента непрерывно корректируется с учетом текущих особенностей бизнеса клиента (например, клиент банка может со временем расширить свой бизнес, с аналогичным изменением характера создаваемых им документов в системе ДБО).

Корректировка статистического профиля осуществляется в автоматическом режиме.

Информация о накопленных статистических данных храниться в базе данных с использованием односторонней хеш-функции. Это означает, что можно проверить профиль для заданного клиента, но нельзя извлечь информацию, к какому клиенту принадлежит конкретный профиль. Такой механизм защиты делает бесперспективной кражу базы статистических данных системы FraudWall потенциальным злоумышленником, что исключает возможность «обхода» правил обнаружения мошеннических платежей, например, создав от имени клиента платеж, соответствующей статистическому профилю.

При обнаружении подозрительного платежа, информация о таком платеже записывается в базу данных PostgreSQL. В дальнейшем информацию о подозрительных платежах из базы PostgreSQL может быть отображена в WWW-интерфейсе системы либо посредством модуля управления передана внешним по отношению к FraudWall системам (например, АБС и т.д.).

Внутреннее взаимодействие всех модулей системы между собой осуществляется через HTTPS-соединение с взаимной аутентификацией по SSL-сертификатам.

Для организации инфраструктуры открытых ключей в системе FraudWall предусмотрен собственный удостоверяющий центр на основе программного обеспечения openssl.

WWW-интерфейс системы доступен пользователям через HTTPS-интерфейс, SSL-сертификат которого автоматически выпускается на удостоверяющем центре системы FraudWall.

При необходимости работы в модуле «FraudWall. Интерфейс системы» с реальными данными, он устанавливается на сервере совместно с модулем «Управляющий WWW-сервер системы Fraudwall».

Данный модуль представляет собой WWW-сервер apache, на котором автоматически настраивается единственный HTTPS-сайт на порту TCP 1000, обрабатывающий запросы пользователя при работе через интерфейс системы.

Для работы в интерфейсе системы FraudWall с реальными данными, пользователь должен авторизоваться в системе. После прохождения успешной аутентификации, пользователю становятся доступны только те операции, которые соответствуют его роли и правам доступа к данным.

Данный модуль представляет собой WWW-сервер apache, на котором автоматически настраивается единственный HTTPS-сайт на порту TCP 1001. Основное его назначение - организация защищенного транспорта передачи запросов от управляющего WWW-сервера к модулю управления системы FraudWall.

Данный модуль представляет собой постоянно запущенный процесс (демон), который обрабатывает запросы от управляющего WWW-сервера по изменению конфигурации сайтов, а также выполняет прочие служебные операции.

Система мониторинга работоспособности компонент системы FraudWall реализована на базе программного обеспечения monit, которая автоматически устанавливается на каждый из серверов, где установлен хотя бы один модуль системы FraudWall.

Система мониторинга автоматически проверяет работоспособность всех сервисов и при обнаружении факта неработоспособности осуществляет их автоматический перезапуск. В сложных случаях, когда перезапуск сервиса не восстанавливает работоспособность модуля, после нескольких попыток перезапуска система мониторинга автоматически перезагружает операционную систему.

Для снижения нагрузки на сервер баз данных PostgreSQL, используемые в текущий и ближайший момент времени данные дополнительно кешируются в системе Memcached. Перед тем, как сделать запрос на выборку данных из СУБД, модули FraudWall первоначально запрашивают эти данные в системе Memcached, тем самым снижая нагрузку на сервер баз данных и повышая общую производительность системы.

В качестве сервера баз данных используется СУБД на основе PostgreSQL.

Архитектура системы FraudWall позволяет реализовать схему, когда часть клиентов будет работать с ДБО через систему FraudWall (с фильтрацией трафика и обнаружением мошеннических платежей), а другая часть клиентов может работать напрямую с сервером ДБО (без фильтрации трафика и обнаружения мошеннических платежей соответственно). Это позволяет протестировать работоспособность и надежность установленной системы FraudWall на период тестирования. Пример такой схемы показан на рисунке:

Рисунок 8. Пример схемы прохождения трафика ДБО на период тестирования

Первый способ не требует каких-либо затрат. Клиенты должны заходить на сайт ДБО не по IP адресу, а по доменному имени, например, https://dbo.bank.ru. Для этого доменного имени в DNS регистрируется 2 записи, соответствующие одному доменному имени, но 2 разным IP адресам в сети Интернет. Балансировка нагрузки осуществляется DNS-сервером, который отдает разным клиентам разный IP адрес

Рекомендуется установить TTL (срок жизни записи в DNS) не более, чем 10 минут. В случае отказа одного из серверов, в DNS удаляется запись с неработоспособным IP адресом, и все клиенты меньше, чем через 10 минут начнут работать с исправным сервером.

Аппаратный балансировщик позволяет эффективнее использовать ресурсы нескольких серверов и гораздо быстрее переключать их в случае отказа.

В качестве операционной системы используется 64-х битная операционная система RedHat Enterprise Linux версии 8.x или 32-х битная операционная система RedHat Enterprise Linux версии 6.x. Получить ISO-образы компакт-дисков операционной системы можно, скачав их непосредственно с сайта после покупки технической поддержки на RedHat Enterprise Linux.

Возможно также скачать ISO-образ, оформив на сайте https://access.redhat.com/downloads/ бесплатную 30-дневную техническую поддержку.

После регистрации на сайте redhat.com, необходимо скачать Binary DVD операционной системы RedHat Enterprise Linux Server 8.x (64-битная для x64):

Рисунок 9. Страница скачивания ISO-образа RedHat Enterprise Linux

После скачивания файла рекомендуется проверить MD5-хеш файла ISO-образа утилитой типа md5sum.

Дистрибутив CentOS распространяется бесплатно с сайта http://www.centos.org/.

Для установки системы FraudWall на CentOS 8.x необходимо скачать ISO-образ первого (DVD-1) инсталляционного диска CentOS под 64-битную архитектуру (имя файла выглядит как CentOS-8.1.1911.1-x86_64-dvd1.iso).

Для установки системы FraudWall на CentOS 6.x необходимо скачать ISO-образ первого (DVD-1) инсталляционного диска CentOS под 32-битную архитектуру (имя файла выглядит как CentOS-6.10-i386-bin-DVD1.iso).

После скачивания файла рекомендуется проверить MD5-хеш файла ISO-образа утилитой типа md5sum.

Для бесплатного скачивания дистрибутива Sun Java JRE, необходимо зайти по ссылке http://www.oracle.com/technetwork/java/javase/downloads/index.html и выбрать Download JRE 7, затем скачать файл с расширением .rpm для Linux x86 (32-bit):

Рисунок 10. Страница скачивания дистрибутива Sun Java JRE

Установка модуля BSI состоит из 2 этапов:

Процедура установки и настройки программного обеспечения модуля BSI следующая:

При установке модуля BSI на сервер анализа трафика, данный сервер фактически выполняет роль WWW-сервера системы BS-Client, с которым работают клиенты банка. Поэтому, в процессе обновления системы BS-Client, необходимо также обновлять содержимое соответствующего WWW-сайта на сервере FraudWall.

Для этого, с помощью Проводника Windows подключитесь с сетевому диску \\IP_адрес\siteN (где N-идентификатор сайта в конфигурации FraudWall) и выложите обновления.

После наката обновлений рекомендуется полностью перегрузить операционную систему как сервера FraudWall, так и сервера RTS

В крупных банках с развитой филиальной сетью, в которых установлено несколько независимых площадок системы ДБО, возникает проблема централизованного администрирования всеми серверами FraudWall: т.к. для каждой независимой площадки ДБО необходима установка независимого комплекта серверов FraudWall. Часто возникает необходимость вмешательства специалистов центрального офиса в деятельность филиалов: помощь при внесении изменений в конфигурацию системы, проверка установленных параметров, просмотр аналитики.

Для решения данной задачи, все сервера FraudWall в филиалах могут быть объединены в единую инфраструктуру, называемую FraudNET.

В инфраструктуре FraudNET один из серверов управления выступает в роли так называемого главного сервера управления. Посредством интерфейса главного сервера можно получить централизованный доступ к любому входящему в инфраструктуру серверу управления, что значительно упрощает администрирование и позволяет отслеживать работоспособность всех серверов FraudWall, участвующих в инфраструктуре FraudNET.

Благодаря синхронизации всех серверов управления филиалов с центральным (с частотой 1 раз в 10 мин), на нем всегда имеется актуальная информация о работоспособности серверов сети, об ошибках возникших в работе FraudWall или других компонент. Также при синхронизации происходит обмен обновленной информацией о мошеннических платежах, что позволяет своевременно оповестить все филиалы и предотвратить массовый увод денег у клиентов.

Для просмотра инфраструктуры сети банка необходимо во вкладке «Система» выбрать раздел «Инфраструктура системы» или нажать на пиктограмму сети в правой нижней части окна.

Рисунок 26. Интерфейс инфраструктуры системы

Проблемные серверы можно легко обнаружить по мигающему красному цвету. При этом выделяется пункт с ошибкой, повлекшей за собой проблемы: обмен с главным сервером управления, обновление FraudWall или ОС и другие. Важной особенностью является то, что при потере сервером филиала соединения с главным сервером управления, не возникает проблем в работе филиала, но теряется возможность обмена данными, поэтому следует как можно скорее устранять подобные разрывы.

Рисунок 27. Информация о сервере

Из интерфейса FraudWall главного сервера управления можно перейти к администрированию любого сервера управления филиала с возможностью полноценной работы в роли администратора, то есть с возможностью внесения изменений в конфигурацию системы, просмотра аналитики, платежей.

Рисунок 28. Выбор сервера управления для администрирования

Система FraudWall является решением, все компоненты которой устанавливаются только в банке. На стороне клиента каких-либо агентов либо специфического программного обеспечения не ставится.

FraudWall также не является облачным решением - вся обработка и хранение данных осуществляется только внутри банка.

С одной стороны, это хорошо - получить несанкционированный доступ к антифрод-системе практически невозможно. Но с другой стороны, такой подход не позволяет учитывать информацию о состоянии компьютера клиента - есть ли на нем вредоносное программное обеспечение, удаленное подключение и т.д.

Для устранения этого недостатка, FraudWall позволяет интегрироваться с облачными решениями сторонних производителей. Данные решения на стороне клиента банка запускают специализированное программное обеспечение, осуществляющее поиск банковских троянов, подозрительной активности на компьютере и т.д.

Результат проверки компьютера клиента банка поступает на сервера облачного провайдера. В свою очередь, FraudWall запрашивает у облачного провайдера результат проверки, а затем учитывает его при анализе платежных поручений, создаваемых в системе ДБО. Такая технология носит название сервис FraudTrack.

FraudWall поддерживает следующих облачных провайдеров:

Общая схема работы сервиса FraudTrack показана на рисунке:

Рисунок 29. Общая схема работы сервиса FraudTrack

Сервер управления при необходимости соединяется с серверами облачного провайдера и получает от них информацию, связанную с состоянием компьютера клиента банка. В дальнейшем, данная информация учитывается при анализе платежных поручений в системе ДБО - если в процессе создания платежки были зафиксирована подозрительная активность на компьютере клиента, такой платеж будет считаться более подозрительным.

Конфигурирование сервиса FraudTrack осуществляется через интерфейс Система\Сайты в группе параметров FraudTrack:

Рисунок 30. Конфигурирование сервиса FraudTrack

Непосредственное взаимодействие с серверами облачного провайдера осуществляет сервер управления - он является инициатором установки TCP-соединения.

На межсетевом экране необходимо дополнительно открыть доступ с сервера управления на сервера облачного провайдера по соответствующим портам.

FraudInform — это автоматизированная система голосового подтверждения подозрительных платежей. Когда антифрод-система FraudWall выявила подозрительный платеж, FraudInform автоматически звонит клиенту и ведет с ним голосовое общение. При этом произносимая речь синтезируется, а ответы клиента распознаются с помощью специализированной системы VoiceNavigator от компании ЦРТ ("Центр Речевых Технологий"). По результатам общения платеж либо исполняется, либо останавливается.

Система FraudInform состоит из 3-х компонент:

Схема взаимодействия компонентов системы представлена на рисунке:

Рисунок 31. Схема взаимодействия компонентов системы FraudInform

После установки и настройки системы FraudWall необходимо выполнить установку компонентов голосовой платформы FraudInform: yum install asterisk-fraudwall

На межсетевом экране необходимо дополнительно прописать следующий доступ:

Установка системы VoiceNavigator осуществляется согласно “Руководству по установке” из архива с дистрибутивом системы. VoiceNavigator устанавливается на отдельном сервере или виртуальной машине с ОС Microsoft Windows Server 2012 R2 Standard.

Необходимые системные требования и требования к программному обеспечению представлены в п.п. 4.1.1 “Требования к вычислительным средствам” и п.п. 4.2.2 “Требования к общему программному обеспечению” руководства по установке.

При использовании пробной версии системы на 4 канала синтеза и распознавания достаточно виртуальной машины с 1 процессором и 1Гб оперативной памяти.

Настройка системы VoiceNavigator осуществляется при помощи утилиты “MRCP Server configuration tool” (Пуск>Speech Technology Center>MRCP Server configuration tool).

В настройках необходимы изменения только в 2-х пунктах, остальные параметры необходимоы оставить по умолчанию:

- в настройках подключения к голосовой платформе в обоих пунктах “IP адрес сервера” и “Внешний IP сервера” необходимо указать IP адрес сервера, на котором развернут VoiceNavigator

Рисунок 32. Настройка подключения к голосовой платформе

- в настройках параметров синтеза значение пункта “Голос по умолчанию” должно быть изменено на Юлия8000

Рисунок 33. Настройка параметров синтеза

Соединение FraudInform с сервером синтеза и распознавания речи VoiceNavigator осуществляется по протоколу MRCPv1, который в свою очередь использует протоколы RTSP и RTP. Конфигурационный файл с настройками данного соединения находится на сервере FraudInform по следующему пути: /etc/asterisk/mrcp.conf.

В этом файле необходимо изменить следующие параметры:

Остальные параметры остаются по умолчанию.

После внесения изменений необходимо выполнить команду: service asterisk restart

Для соединения FraudInform с АТС Банка используется протоколы SIP и RTP, настройка осуществляется в файле /etc/asterisk/sip_ats.conf.

В этом файле необходимо изменить следующие параметры:

После внесения изменений необходимо выполнить команду: service asterisk restart

В системе FraudInform предусмотрено автоматическое преобразование телефонных номеров, содержащих код города, а также номеров сотовых операторов к 11-ти значному формату вида 7xxxxxxxxxxx. Телефонные номера, в которых не указан код города, а также внутренние номера набираются как цифры.

Если банковская АТС не поддерживает набор номера в таком формате, в системе FraudInform предусмотрены правила корректировки номера телефона перед передачей его в банковскую АТС. Для таких целей используется конфигурационный файл /etc/asterisk/dialog_dial.conf

По умолчанию в этом файле прописаны следующие правила преобразования телефонного номера:

Если в банковской АТС другие требования к набору номера, необходимо подкорректировать эти правила. После внесения изменений необходимо выполнить команду: service asterisk restart

Настройки специфичных для банка параметров диалога с клиентом осуществляется в файле /etc/asterisk/dialog_vars.conf.

В этом файле необходимо изменить следующие параметры:

После внесения изменений необходимо выполнить команду: service asterisk restart

Сценарий разговора с клиентом может быть отредактирован в зависимости от требований банка. Например, можно изменить текст, который будет произнесен клиенту, либо полностью изменить сценарий общения.

Сценарий диалога с клиентом банка конфигурируется в файле /etc/asterisk/dialog.conf

После внесения изменений необходимо выполнить команду: service asterisk restart

Активация процесса автоматического обзвона клиентов осуществляется через интерфейс Система\Сайты в группе параметров FraudInform:

Рисунок 34. Вкладка конфигурирования FraudInform

Здесь же устанавливается максимальная сумма платежа для автоматического подтверждения. Подозрительные платежи на очень большие суммы рекомендуется подтверждать с помощью "живого" общения сотрудника банка с клиентом.

Для успешного общения с клиентом системе FraudInform необходимо одновременное выполнение следующих требований:

Перед началом тестирования необходимо в консоли сервера управления FraudWall выполнить команду (число символов v в командной строке нужно не менее 5): asterisk -rvvvvvvvvvvvvvvvvv

Начинать тестирование системы рекомендуется, подключившись к Asterisk на сервере управления FraudWall с помощью программного SIP-софтфона (например программных софтфонов X-Lite или Ekiga) и, подключенных к компьютеру, динамика с микрофоном.

В настройках подключения софтфона необходимо указать следующие настройки (они прописаны в файле /etc/asterisk/sip_test.conf):

После успешной регистрации софтфона на нем необходимо набрать номер 101. В ответ вы услышите приветствие и голосовое меню диагностики подключений системы. А затем, набрав на клавиатуре софтфона цифру 1, вы должны услышать голос, синтезируемый сервером VoiceNavigator.

Если в ответ тишина, первоначально нужно убедиться в отсутствии ошибок, выводимых в консоли запущенного ранее asterisk. Если есть ошибки - соответственно попытаться устранить их либо самостоятельно, либо с помощью технической поддержки.

Для диагностики подключения к АТС Банка необходимо набрать номер 101 с софтфона, дождаться ответа от голосового меню, а затем набрать номер телефона для звонка через АТС (можно делать тестовый звонок как на внутренний номер, так и на городской номер).

Если в консоли asterisk отсутствуют какие-либо ошибки, но при этом в трубке "тишина", необходимо проверить наличие доступа на межсетевом экране, а также отсутствие каких-либо трансляций SIP-трафика в конфигурации АТС.

Если в трубке слышна синтезируемая речь, но наблюдаются характерные "бульки", необходимо удостоверится, что в АТС приоритетным является кодек alaw (остальные кодеки лучше вообще отключить).

При корректной конфигурации всех компонент системы FraudInform и выполнении всех необходимых требований для его работы, обзвон клиентов начнется автоматически.

Система FraudInform ведет запись всех разговоров с клиентами Банка.

Записи храняться в каталоге /var/spool/asterisk/monitor в формате .wav

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

Несмотря на то, что сервер с установленной системой FraudWall рассчитан на автономную многолетнюю работу, ряд операций, связанных с администрированием операционной системы, придется выполнять вручную.

Для администрирования операционной системы RedHat Enterprise Linux рекомендуется пройти обучение на соответствующих курсах в специализированных учебных центрах.

Для получения помощи по использованию команд необходимо выполнить команду: man имя_команды

На большинство вопросов можно получить ответ, воспользовавшись поисковыми системами в сети Интернет.

Более детальную информацию по условиям технической поддержки RedHat можно уточнить на сайте компании RedHat.

Системное администрирование сервера с FraudWall осуществляется по протоколу SSH (см. раздел 5.1.2 «Администрирование через SSH-консоль»).

Для обмена файлами с сервером предусмотрено 2 варианта:

Существует также Web-интерфейс системы мониторинга, доступный по протоколу HTTP на порту TCP 2812, позволяющий посмотреть статус контролируемых сервисов в режиме «только чтение».

Консольное администрирование всех серверов с системой FraudWall осуществляется по шифрованному протоколу SSH.

В качестве SSH-клиента можно использовать любое программное обеспечение, например, PuTTY. В настройках SSH-клиента необходимо указать кодировку символов UTF-8:

Рисунок 35. Выбор кодировки для администрирования

Обмен файлами посредством протоколов SCP и SFTP осуществляется внутри шифрованного SSH-туннеля.

На компьютер администратора необходимо установить соответствующее программное обеспечение, например, WinSCP. В настройках SSH-клиента необходимо указать кодировку символов UTF-8.

Для увеличения скорости передачи файлов по протоколу SCP(SFTP), во вкладке [SSH] рекомендуется установить алгоритм шифрования blowfish первым используемым алгоритмом. Например, для плагина WinSCP к файловому менеджеру FAR такая настройка выглядит следующим образом:

Рисунок 36. Выбор алгоритма шифрования

Для упрощенных задач администрирования предусмотрен обмен файлами посредством сетевых дисков сети Microsoft.

Для подключения к сетевым дискам сервера FraudWall, необходимо в Проводнике открыть путь \\IP_адрес_сервера, либо найти компьютер в сети Microsoft с соответствующим именем (рабочая группа WORKGROUP):

Рисунок 37. Подключение к сетевым дискам сервера FraudWall

В операционной системе предусмотрены следующие учетные записи, посредством которых можно подключиться к сетевым дискам сервера FraudWall:

В качестве пароля необходимо использовать соответствующий пароль в операционной системе, заданный с помощью утилиты fw_passwd

На сервере предусмотрены следующие сетевые диски:

При установке системы пользователю root, обладающему неограниченными правами в операционной системе, присваивается пароль 12345.

Для изменения пароля пользователя операционной системы необходимо выполнить команду: fw_passwd имя_пользователя

Существует также ряд команд по созданию (useradd), удалению (userdel) пользователей и групп (groupadd и groupdel соответственно) - более подробное описание их можно получить в специализированной литературе по администрированию операционной системы Linux.

Для сетевого взаимодействия в системе используется один Ethernet-адаптер со статическим IP адресом.

Для изменения сетевых настроек необходимо выполнить команду: service fw_setup start

После указания сетевых настроек, они вступают в силу сразу по завершению выполнения команды.

На сервере отключена локальная служба межсетевого экранирования. Для защиты сервера FraudWall от несанкционированного доступа по сети необходимо использовать специализированные сторонние межсетевые экраны.

Полный перечень сетевых портов, необходимых для написания правил межсетевого экранирования, приведен в таблице:

Журналы событий всех процессов сервера хранятся в файлах в директории /var/log.

Дата и время во всех журналах событий представлено во временной зоне UTC (GMT). На 1 января 2012г. время в зоне UTC отставало от московского на 4 часа (т.е. если московское время 14:00, время события в журнале событий будет зафиксировано как 10:00).

Назначение основных файлов журналов приведено в таблице:

Каждую ночь автоматически осуществляется переключение файлов старых журналов событий и помещение их в архивные файлы в директорию /var/log/archive.

Имя архивного файла формируется по правилу: тип-датаГГГГММДД_времяЧЧММСС-имя_сервера.расширение

В качестве программы - архиватора используется rar (если установлен), либо tar с сжатием BZIP2 (если не установлен rar). В соответствии с используемым архиватором, расширение будет .rar либо .tar.bz2.

В случае использования программы - архиватора rar, возможно дополнительное шифрование содержимого архивов по паролю. Пароль шифрования указывается в параметре archive_password в конфигурационном файле fwcontrol.xml.

Рекомендуется ежедневно переносить архивные файлы с журналами событий, созданные в директории /var/log/archive (сетевой диск archive), на внешний носитель.

Рекомендуется обновлять программное обеспечение операционной системы в малозагруженное время, но не реже, чем 1 раза в неделю.

Рекомендуется также периодически просматривать файлы журналов событий на наличие критичных записей (ошибки обновления, проблемы в работе и т.д.).

Рекомендуется периодически формировать архивный образ жестких дисков всех серверов системы специализированными средствами создания резервных копий.

Служебные конфигурационные файлы компонент системы FraudWall располагаются в директории /etc/fraudwall (файлы fwcontrol.xml и fraudwall.xml).

Прикладное администрирование системы FraudWall осуществляется через WWW-интерфейс.

Конфигурационный файл fwcontrol.xml представляет собой XML-файл в кодировке UTF.

Данный файл содержит в себе параметры ограниченного доступа, которые должны быть доступны только пользователю root.

Синтаксис строки параметра следующий:

<option name="параметр" value="значение"/>

Изменить логин и пароль администратора баз данных можно, выполнив на сервере, где установлены компоненты базы данных FraudWall, команду: fw_dbadmin

После внесения изменений в файл fwcontrol.xml необходимо выполнить команду: service fw_control restart

Конфигурационный файл fraudwall.xml представляет собой XML-файл в кодировке UTF.

Данный файл содержит в себе параметры, необходимые для взаимодействия различных компонент системы FraudWall между собой.

Синтаксис строки параметра следующий:

<option name="параметр" value="значение"/>

Администрирование пользователей системы FraudWall осуществляется посредством WWW-интерфейса в пункте «Администрирование» меню «Пользователи»:

Рисунок 38. Интерфейс администрирования пользователей системы FraudWall

Для редактирования свойств существующего пользователя необходимо ввести в поле «Пользователь» логин пользователя либо его фамилию, затем нажать Enter.

Установить (сбросить) первоначальный пароль входа пользователя можно, указав новый пароль в поле «Установить первоначальный пароль», затем нажать на кнопку «Сохранить»:

Рисунок 39. Сброс пароля пользователя

Можно временно заблокировать пользователя, нажав на кнопку «Заблокировать». Разблокирование пользователя осуществляется нажатием на кнопку «Разблокировать».

При удалении пользователя соответствующая учетная запись помечается со статусом «Удален». Восстановить удаленного пользователя невозможно.

Права доступа каждого пользователя в системе определяются его ролью, а также перечнем допустимых кодов БИК банка плательщика, масок расчетных счетов плательщика.

Перечень допустимых операций каждой роли можно посмотреть в помощи к параметру «Роль пользователя»:

Рисунок 40. Роли пользователей системы FraudWall

Списки допустимых БИК банка плательщика и масок расчетных счетов плательщика работают по принципу - если указано хотя бы одно значение в списке, то пользователю доступны платежи только попадающие под этот список. Если в списке значений нет, то ограничений доступа по соответствующему списку пользователю не накладывается.

Для удобства администрирования пользователей, имеющих идентичные права доступа (например, сотрудники бэк-офиса одного и того же филиала банка), можно настроить права доступа одному из пользователей, а затем скопировать его права другим пользователям. При копировании прав доступа пользователю, ранее существующие у него права будут полностью заменены.

Аутентификация пользователей FraudWall может осуществляться как на основе локального пароля (на уровне FraudWall), так и по паролю пользователя в ActiveDirectory.

При этом допускается, что некоторые пользователи будут аутентифицироваться по паролю FraudWall, а некоторые - по паролю ActiveDirectory.

Для того, чтобы пользователь FraudWall мог быть аутентифицирован по паролю ActiveDirectory, при его создании необходимо указать домен ActiveDirectory в виде DOMAIN\USERNAME, как показано на рисунке:

(при этом первоначальный пароль указывать не нужно).

Если же пользователь был создан без указания домена ActiveDirectory, FraudWall рассматривает его как пользователя, аутентификация которого осуществляется по локальному паролю FraudWall. Например, таким пользователем является пользователь admin.

Также для аутентификации пользователей ActiveDirectory необходимо в параметре ad_server конфигурационного файла /etc/fraudwall/fraudwall.xml указать IP адрес контроллера домена ActiveDirectory. Включение сервера FraudWall в домен ActiveDirectory не требуется.

...
<!-- IP адрес контроллера Active Directory -->
<option name="ad_server" value="1.2.3.4"/>
</config>

После внесения изменений в конфигурационный файл fraudwall.xml необходимо выполнить команду:

service fw_master restart

Для диагностики проблем, связанных с процессом аутентификации пользователей в домене ActiveDirectory, FraudWall фиксирует статус аутентификации в журнале аудита действий пользователей системы, доступный через интерфейс "Аудит пользователей" меню "Пользователи".

В процессе первоначальной установки создается встроенный администратор системы ‘admin’ с паролем ‘admin’.

В целях безопасности пароль этого пользователя рекомендуется изменить на более сложный.

Если в процессе эксплуатации системы новый пароль пользователя ‘admin’ был забыт, то возможно сбросить его на первоначальное значение. Для этого, необходимо зайти SSH-консолью под учетной записью root и выполнить команду: fw_control -c resetadmin

В файле журнала событий модуля управления /var/log/fraudwall/fw_control.log будет зафиксирована соответствующая запись о результате выполнения команды.

Действие пользователей в WWW-интерфейсе системы FraudWall протоколируется в журнале аудита. Просмотр событий журнала аудита осуществляется в WWW-интерфейсе системы FraudWall, пункт «Аудит пользователей» меню «Пользователи»:

Рисунок 41. Интерфейс аудита системы FraudWall

Интерфейс аудита позволяет найти события в том числе по удаленным пользователям системы FraudWall.

Все настройки по обнаружению мошеннических платежей хранятся в так называемых профилях.

Профили могут быть применены на уровне клиента, на уровне сайта и на уровне филиала (банка). Приоритетным считается профиль на уровне клиента, если он не указан, то используется профиль на уровне сайта, если на уровне сайта профиль также не указан, используется профиль на уровне филиала (банка).

Один и тот же профиль может быть применен к нескольким филиалам банка, нескольким сайтам и нескольким клиентам.

Редактирование свойств профиля осуществляется в пункте «Профили антифрода» меню «Система»:

Рисунок 42. Интерфейс редактирования свойств профиля

В рабочей системе FraudWall должен быть создан как минимум один профиль, и к каждому банку (филиалу) должен быть привязан профиль.

Привязка профиля к банку либо его филиалу осуществляется при конфигурировании свойств филиала (пункт «Филиалы» меню «Система»):

Рисунок 43. Привязка профиля к банку либо его филиалу

Привязка профиля к сайту осуществляется при конфигурировании свойств сайта (пункт «Сайты» меню «Система», «Общие параметры»):

Рисунок 44. Привязка профиля к сайту

Привязка профиля к клиенту банка осуществляется в интерфейсе получение аналитических отчетов по клиенту (интерфейс «Плательщик» меню «Аналитика»):

Рисунок 45. Привязка профиля к клиенту банка

Система FraudWall обнаруживает мошеннические платежи только для тех банков (филиалов), на которые есть соответствующая лицензия. Привязка осуществляется по коду БИК.

Один и тот же сервер FraudWall может анализировать трафик и обнаруживать мошеннические платежи клиентов одновременно нескольких филиалов.

Как показывает практика, клиенты разных филиалов одного и того же банка, имеют свою специфику, связанную с особенностью региона, где расположен филиал. Помимо разного значения средних сумм платежей, которое уже упоминалось в разделе 5.2.8 «Конфигурирование профилей обнаружения мошеннических платежей», это может быть часовой пояс, в котором работают клиенты, либо другие параметры.

В системе FraudWall предусмотрена возможность устанавливать каждому филиалу собственные настройки, либо использовать типовые правила и параметры обнаружения мошеннических платежей.

Рисунок 46. Интерфейс редактирования свойств банка либо филиала

Клиенты, работая в системе ДБО, фактически работают на Web-сайте, который создан на WWW-сервере системы ДБО.

Так как для фильтрации трафика и обнаружения мошеннических платежей весь трафик клиентов должен проходить через систему FraudWall, в системе FraudWall для каждого из таких Web-сайтов ДБО создаются собственные настройки.

Для того, чтобы трафик клиентов проходил через систему FraudWall, на сервере FraudWall есть WWW-сервер Apache, с которым должен соединяться клиент для работы с ДБО.

Интерфейс конфигурирования Web-сайтов системы FraudWall доступен через пункт «Сайты» меню «Система»:

Рисунок 47. Интерфейс редактирования свойств Cайта FraudWall

Один и тот же сервер FraudWall может работать одновременно с несколькими Web-сайтами системы ДБО. Единственное ограничение - если модуль BSI системы ДБО BS-Client устанавливается непосредственно на сервер FraudWall, то на этом сервере может быть настроен только один сайт с модулем BSI (при этом, Web-сайтов, работающих в проксированном режиме, может быть несколько).

При конфигурировании Web-сайта, работающего по шифрованному протоколу HTTPS, необходимо установить SSL-сертификат из файла формата PKCS#12, содержащего в том числе сертификаты всех вышестоящих удостоверяющих центров, на которых выпущен SSL-сертификат. Процедура импорта SSL-сертификата из операционной системы Microsoft Windows приведена в разделе 4.7 «Установка сервера управления системы FraudWall» .

SSL-сертификат в конфигурации Web-сайта системы FraudWall достаточно установить один раз - при последующем изменении параметров этого Web-сайта повторно импортировать SSL сертификат из файла не потребуется.

Можно настроить кеширование данных Web-сайта, что может снизить нагрузку на WWW-сервер системы ДБО, а также объем передаваемых данных между сервером FraudWall и WWW-сервером:

Рисунок 48. Настройка кеширования Web-сайта FraudWall

Более подробно о кешировании трафика см.раздел 5.2.11 «Кеширование трафика на стороне FraudWall».

Трафик клиентов при работе в ДБО, который используется для обнаружения мошеннических платежей, помещается в файл. Учитывая сложность работы с файлами большого размера, в системе FraudWall предусмотрена возможность переключения файла (т.е. создание нового файла с переименованием существующего) при превышении заданного размера файла:

Рисунок 49. Настройка максимального размера файла дампа

Срок устаревания содержимого, сообщаемого WWW-сервером системы ДБО клиенту, носит не обязательный, а рекомендательный характер.

В некоторых случаях Internet-браузер на стороне клиента игнорирует параметры срока устаревания содержимого.

Например, при включении указанных ниже опций Internet Explorer может запрашивать у Web-сервера файл, срок устаревания которого с последнего посещения страницы сайта еще не прошел:

Рисунок 50. Параметры Internet Explorer, при которых игнорируется устаревание кеша

В этом случае Internet Explorer формирует много паразитного трафика, состоящего из множества запросов на получение одной и той же картинки, css-файла и т.д. Такой трафик повышает нагрузку на Web-сервер системы ДБО, систему FraudWall и т.д.

Исходя из особенностей Internet Explorer, кеширование на стороне FraudWall дает наибольший эффект для сайтов, работающих через шифрованный протокол HTTPS.

При включении кеширования на стороне FraudWall, если запрашиваемое клиентом статическое содержимое находится в кеше, то этот запрос уже не будет перенаправлен на WWW-сервер ДБО, и клиенту будет отправлено закешированное содержимое. Таким образом, WWW-сервер ДБО будет заниматься в основном формированием динамического содержимого.

Срок устаревания данных в кеше аналогичен параметрам устаревания содержимого, указанных в конфигурации Web-сервера:

Рисунок 51. Настройка устаревания содержимого в WWW-сервере IIS

Для создания отказоустойчивой схемы и балансировки нагрузки можно использовать несколько WWW-серверов системы ДБО.

Каждый из WWW-серверов системы ДБО должен иметь идентичную конфигурацию программного обеспечения: настройки WWW-сервера, содержимое сайтов и т.д.

Балансировка нагрузки между WWW-серверами системы ДБО предусматривает также автоматическое отключение отказавшего WWW-сервера, т.е. отказоустойчивую среду.

Схема балансировки нагрузки показана на рисунке:

Рисунок 52. Балансировка WWW-серверов ДБО средствами FraudWall

Список внутренних WWW-серверов, участвующих при балансировке нагрузки одного Web-сайта, указывается в WWW-интерфейсе FraudWall при конфигурировании Web-сайта:

Рисунок 53. Список внутренних WWW-серверов при балансировке нагрузки

Приоритет WWW-сервера означает соотношение числа обрабатываемых запросов из общего числа - чем больше приоритет, тем больше на него будет перенаправлено запросов. Например, если приоритет 1-го сервера 10, а 2-го сервера 20, то из 30 запросов 10 будут отправлены на 1-й сервер, а 20 оставшихся запросов - на 2-й.

Для корректной балансировки нагрузки между WWW-серверами необходимо, чтобы Internet-браузер на стороне клиента поддерживал Cookie. Если в Internet-браузере клиента поддержка Cookie отключена, то все его запросы будут перенаправляться на первый работоспособный сервер из списка внутренних WWW-серверов.

При включенной поддержке Cookie на стороне клиента, он будет обслуживаться только тем WWW-сервером ДБО, который обрабатывал его первый запрос.

Можно также реализовать схему, при которой, помимо балансировки WWW-серверов системы ДБО, осуществляется балансировка серверов FraudWall:

Рисунок 54. Одновременная балансировка серверов FraudWall и WWW-серверов ДБО

Система FraudWall автоматически вычисляет число используемых лицензий на основе данных о платежах клиентов, полученных в процессе обучения системы (т.е. из VIEW fraudwall_learn).

При приближении числа используемых лицензий к максимальному значению, система FraudWall формирует администраторам сервера письмо с соответствующим предупреждением.

Возможна ситуация, когда клиент банка закрывает расторгает договор с банком об обслуживании расчетного счета, и выделять для него лицензию FraudWall нецелесообразно. В этом случае предусмотрено три варианта высвобождения лицензии:

СУБД PostgreSQL, используемая в качестве хранилища данных в системе FraudWall, отличается высокой надежностью в своей работе. Конфигурационные файлы, поставляемые по-умолчанию, рассчитаны на многолетнюю необслуживаемую работу.

Тем не менее, могут возникнуть следующие проблемы:

Для решения таких проблем предусмотрена утилита, которая пересоздает файлы базы данных, уменьшая их в размере и исправляя при этом возможные проблемы. Для ее запуска необходимо выполнить команду fw_dbshrink

В процессе первоначального тестирования системы, FraudWall, как правило, обрабатывает тестовые несуществующие платежи, которые отсутствуют в боевой базе ДБО или АБС. Поэтому после завершения этапа тестирования, база данных статистики FraudWall может быть искажена.

Чтобы в промышленной эксплуатации FraudWall работал только с корректной базой данных статистики, предусмотрена возможность полного очищения базы данных FraudWall. Для этого необходимо в SSH-консоли выполнить команду: fw_dbclear

Предполагаются следующие возможные варианты создания архивной копии конфигурации FraudWall:

Утилита fw_backup позволяет сохранить конфигурацию сервера FraudWall, а также содержимое базы данных FraudWall, в архивном файле.

Данная процедура также позволяет мигрировать сервер FraudWall на другой физический сервер, т.к. архивный файл может быть восстановлен на другом сервере.

Создание архива может быть выполнено как в интерактивном режиме, так и как cron-задание.

Созданный архив будет находится в директории /var/tmp/ с именем файла вида fwbackup-ГГГГММДД_ЧЧММСС-имясервера.tgz, который необходимо вручную перенести с сервера FraudWall на сервер хранения архивов.

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

Создание архива можно автоматизировать, например, как еженочное создание архива.

Для выполнения утилиты fw_backup в скриптах предусмотрен параметр -c. После завершения работы, fw_backup возвращает код возврата 0 при успехе, а при ошибке - ненулевое значение.

При конфигурировании автоматического создания архива на сервере управления убедитесь, что в конфигурационном файле /var/lib/pgsql/data/postgresql.conf есть следующие параметры:

archive_mode = on
archive_command = '/usr/sbin/fw_dbwal "%p" "%f"'
archive_timeout = 0

Если указанные параметры отличаются, подкорректируйте их, а затем перегрузите сервер командой reboot

Пример скрипта, который будет выполнять автоматическое создание архива, следующий:

#!/bin/bash

# Создаем архив в /var/tmp
/usr/sbin/fw_backup -c
RETVAL=$?
if [ $RETVAL -ne 0 ]; then
  echo "Error"
  exit 1
fi

# Копируем архив из /var/tmp на другой сервер по SCP
scp /var/tmp/fwbackup* user@arcserver:/mnt/backup/

# Удаляем архив из /var/tmp
rm -f /var/tmp/fwbackup*

Утилита fw_restore позволяет восстановить сервер FraudWall из архивной копии, в том числе на другом физическом сервере.

Восстановление сервера осуществляется в следующей последовательности:

После восстановления сервера из snapshot-образов или посекторной копии жесткого диска, сервер FraudWall необходимо перегрузить командой reboot

Если восстанавливается сервер баз данных FraudWall (как правило, это сервер управления), после восстановления и перезагрузки сервера, необходимо дополнительно выполнить команду: fw_control -c dbfix

По завершению данной команды сервер считается восстановленным.

Миграция сервера FraudWall, как правило, осуществляется при необходимости расширить аппаратные ресурсы сервера (например, увеличить дисковое пространство), либо при смене операционной системы (например, с RedHat на бесплатный CentOS).

Миграция осуществляется с помощью утилиты fw_backup.

Если в установлен дополнительный сервер анализа трафика, первоначально необходимо мигрировать сервер управления FraudWall.

Если размер базы данных на сервере FraudWall превышает несколько десятков гигабайт, восстановление сервера из архива займет значительное время. Поэтому в FraudWall предусмотрена возможность создания горячего резерва сервера базы данных.

Горячее резервирование подразумевает, что в банке установлено минимум 3 сервера:

Резервный сервер FraudWall может быть установлен после установки основного сервера в любой момент времени.

При отказе основного сервера, резервный может полностью быть восстановлен как основной сервер, в т.ч. резервный сервер может подхватить IP адреса отказавшего сервера.

Конфигурирование серверов, включая переконфигурирование резервного сервера на работу как основной сервер, осуществляется вручную из командной строки операционной системы.Для работы с горячим резервированием серверов предусмотрена команда fw_dbha

Для создания резервного сервера необходимо:

Процедура восстановления подразумевает, что резервный сервер будет полностью переконфигурирован как отказавший основной сервер, в т.ч. на резервном сервере будут восстановлены сетевые настройки (IP адрес) основного сервера.

Для восстановления системы необходимо:

После того, как резервный сервер взял на себя функционал основного (т.е. фактически стал основным сервером и стал обслуживать IP адрес основного сервера), бывший основной сервер должен оставаться выключенным, т.к. на нем остался тот же IP адрес и при его включении возникнет конфликт адресов.

Процедура его обратного включения заключается в том, что он восстанавливается как резервный сервер, в т.ч. с переформатированием жестких дисков и установкой чистой операционной системы (более детально см. раздел 5.4.2 «Создание резервного сервера»).

Если восстановленный сервер (он теперь выступает в роли резервного сервера) является более быстрым, имеет смысл дополнительно сделать его опять основным согласно следующей последовательности (эту процедуру лучше делать во внерабочее время):

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

Для этого необходимо:

В конфигурации профиля есть параметр - Использование встроенных правил, который определяет число активированных встроенных правил для данного профиля.

Рисунок 59. Использование встроенных правил

Все встроенные правила сгруппированы таким образом, чтобы их уровень срабатывания относился к среднестатистическим показателям мошеннических платежей, наблюдаемых в процессе разработки системы FraudWall. Разработчиком определены следующие уровни срабатывания встроенных правил:

Для обнаружения подавляющего большинства мошеннических платежей для среднестатистических клиентов рекомендуется использовать рекомендуемый набор правил. Более низкие уровни рекомендуется устанавливать на отдельных клиентов, если по ним наблюдается высокий уровень ложного срабатывания и клиент принимает риски возможного ущерба от мошеннических платежей.

Можно полностью отключить использование встроенных правил, установив значение параметра «Использование встроенных правил» как «отсутствует» (например, если необходимо использовать только правила, созданные вручную).

Вне зависимости от параметра «уровень использования встроенных правил», FraudWall проверяет также правила, созданные вручную на стороне банка.

Каждое правило содержит набор критериев, которые должны одновременно выполниться, чтобы сработало правило. Например, если в правиле указаны критерии «Сумма платежа свыше 1000000 рублей», «Значение (сумма платежа) / (остаток на счете) больше 0.8», то правило сработает на платежи свыше 1000000 руб. и если сумма платежа составит свыше 80% от остатка на счете.

Правила проверяются сверху вниз до срабатывания первого правила вида «платеж создан клиентом». Правила этого вида необходимы для того, чтобы исключить срабатывание созданных вручную правил на платежи на небольшие суммы, либо на переводы между своими счетами и т.д. Например, если требуется, чтобы созданные вручную правила обнаружения мошеннических платежей не срабатывали на платежи суммой ниже 25000 рублей и на платежи между своими счетами, то в самом начале списка правил необходимо создать 2 правила вида «платеж создан клиентом»: первое правило с критерием «сумма платежа меньше 25000 рублей, а второе правило - с критерием «платеж между своими счетами».

Интерфейс редактирования правил позволяет перемещать правило как вверх по списку (повышая его приоритет), так и вниз. Созданное вручную правило можно отключить на необходимое время (например, если созданное правило приводит к большому числу ложных срабатываний, его можно временно отключить для более детального анализа), а также удалить без возможности восстановления.

На один и тот же документ может сработать одновременно несколько правил. Система FraudWall будет считать платеж подозрительным, если сработало хотя бы одно из встроенных правил, либо созданных вручную вида «подозрительный платеж».

Ограничений как на число созданных вручную правил, так и на число критериев в одном правиле не накладывается.

В зависимости от способа интеграции с системой ДБО, а также версии самой ДБО, значение некоторых флагов выставляется как «НЕИЗВЕСТНО», а для числовых флагов - соответствующий критерий никогда не сработает.

Например, в универсальном режиме интеграции с ДБО (анализ платежей непосредственно в базе данных) информацию о времени просмотра остатка на счете вычислить, как правило, невозможно. Если создано ручное правило «сумма платежа свыше 100 000 рублей» и «время создания документа после просмотра остатка меньше 120 секунд», то оно никогда не сработает.

В таких случаях рекомендуется использовать условие не «ЗНАЧЕНИЕ = ПРАВДА», а «ЗНАЧЕНИЕ != ЛОЖЬ» - в этом случае под правило попадают не только платежи, у которых ЗНАЧЕНИЕ = ПРАВДА, но также и платежи, когда значение параметра вычислить невозможно.

Как и любая система принятия решений, FraudWall может ошибочно считать документы подозрительными (ошибка первого рода, или ложное срабатывание).

Для определения наиболее часто срабатывающих правил, в системе FraudWall предусмотрен удобный интерфейс получения аналитических и статистических отчетов по срабатыванию правил (пункт «Статистика - правила» меню «Аналитика»).

Для определения массовости проблемы необходимо воспользоваться интерфейсом поиска платежей (Пункт «Все» меню «Платежи»). В критериях поиска платежей необходимо задать номер анализируемого правила:

Рисунок 62. Поиск документов по правилу с заданным номером

Результат выборки будет содержать платежи всех клиентов, которые сработали по заданному номеру правила.

Если проблема носит частный характер, т.е. ложное срабатывание свойственно только некоторым клиентам, рекомендуется создать для них собственный профиль обнаружения мошеннических платежей, в котором указать другой диапазон сумм, набор правил и т.д.

Привязать профиль к клиенту можно через интерфейс просмотра аналитики по клиентам банка (интерфейс «Плательщик» меню «Аналитика»):

Рисунок 63. Установка профиля на уровне клиента банка

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

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

В процессе своей работы на каждом сервере FraudWall в директории /var/log/archive/statistics формируются обезличенные лог-файлы обработки платежных поручений. Эти файлы могут быть проанализированы с целью поиска оптимальных значений параметров обнаружения как на стороне банка, так и на стороне технической поддержки.

Для автоматизированного анализа обезличенных лог-файлов предусмотрена утилита fw_forecast.С ее помощью можно определить оптимальные значения пороговых сумм профилей обнаружения мошеннических платежей, а также спрогнозировать уровень ложного срабатывания при добавлении в профиле каких-либо правил, созданных вручную.

Для ее запуска необходимо выполнить команду: fw_forecast -i ID

где ID - идентификатор профиля, настройки которого будут анализироваться - его можно посмотреть в Web-интерфейсе "Система\Конфигурирование\Профили". Чтобы оценить уровень ложного срабатывания с настройками по умолчанию, укажите значение "0".

Перед началом анализа данных необходимо определить, за какой период будут обрабатываться данные:

Для разархивирования файлов с расширением .tar.bz2, в SSH-консоли необходимо выполнить команду: tar -x -j -f ИмяФайла.tar.bz2 -C ДиректорияАнализа

Файл дампа содержит информацию по сессиям всех клиентов банка. Чтобы работать только с нужной информацией, необходимо выбрать критерии извлечения данных.

Критерии фильтрации указываются как опции в командной строке при вызове утилиты формирования файлов дампа.

Можно указать один или одновременно несколько фильтров:

Если указано два и более критерия отбора, они работают по принципу "ИЛИ".

В зависимости от системы ДБО, используются разные утилиты обработки файлов дампа:

При вызове утилиты анализа дампов необходимо указать следующие опции:

Результатом работы утилиты будет набор файлов, содержащих дамп работы каждой из сессий клиентов с учетом заданных критериев фильтрации.

Примеры использования утилиты обработки файла дампа:

Файл, используемый утилитой обучения статистических профилей клиентов, представляет собой текстовый файл следующего формата:

Дата документа`Наименование плательщика`ИНН плательщика`БИК банка плательщика`Р/с плательщика`Наименование получателя`ИНН получателя`БИК банка получателя`Р/с получателя`Сумма платежа`Назначение платежа

Каждая строка текстового файла содержит информацию об одном платеже и завершается символами перевода строки DOS-файла (два байта шестнадцатеричного значения 0D и 0A).

Символ разделения полей данных - ` (шестнадцатеричный ASCII-код 60). Кодировка всех символов - Windows 1251.

Значение поля ИНН получателя может быть пустым. Остальные поля должны содержать непустое значение. Ведущие и завершающие пробелы для каждого поля игнорируются.

Утилита обучения запускается на сервере управления системы FraudWall.

Прервать процесс импорта (с возможностью продолжения с места остановки) можно, нажав Ctrl+C в SSH-консоли, где запущена команда fw_import.

В случае критических ошибок, а также завершения процесса fw_import, создается файл с именем, аналогичным имени файла с выгруженными данными, с добавлением .last в конце. В этом файле фиксируется последняя обработанная строка файла выгруженных данных.

При повторном запуске процедуры импорта, утилита первоначально пытается открыть файл с окончанием .last. Если он найден, то импорт начинается с той строки, номер которой записан в этом .last - файле. Это удобно, если необходимо временно прекратить процесс импорта данных.

Ручной ввод информации о получателях возможен через WWW-интерфейс системы (интерфейс «Получатель» меню «Аналитика»).

Рисунок 66. Интерфейс аналитики по получателю - физическому лицу

Можно помещать получателя (даже если по нему отсутствует накопленная статистика) в черный список (статус «все платежи на данного получателя считать мошенническими»), помещать в белый список (статус «все платежи на данного получателя считать хорошими»), а также удалять из него (статус «анализировать платежи на данного получателя как обычно»).

Для выполнения процедуры импорта достаточно перенаправить (forward) письмо, содержащее Excel-файл с черным списком, на адрес fwblack@IP_адрес_сервера_управления. Например, если IP адрес сервера управления 192.168.1.1, то почтовое сообщение необходимо перенаправлять на адрес fwblack@192.168.1.1

Проверить выполнение процедуры импорта вы можете, воспользовавшись интерфейсом получения аналитики по получателю (пункт "Получатель" в меню "Аналитика").

Рекомендуется настроить автоматическое перенаправление таких писем в систему FraudWall, т.к. в этом случае процесс импорта не будет зависеть от того, находится ли сотрудник на рабочем месте или нет.

В FraudWall можно импортировать Excel-файл, полученного в рамках межбанковского почтового обмена, также через WWW-интерфейс системы FraudWall.

Для импорта Excel-файла необходимо зайти в интерфейс "Аналитика по получателю", нажать на кнопку "Импорт черного списка получателей", а затем указать Excel-файл:

Рисунок 68. Кнопка для импорта черного списка получателей

При выставлении в интерфейсе системы FraudWall документу статуса "мошеннический", появляется дополнительная кнопка "Подготовить Excel-файл для антидроп-клуба":

Рисунок 69. Интерфейс формирования файла для антидроп-клуба

При нажатии этой кнопки, будет автоматически сформирован Excel-файл, в котором будут заполнены реквизиты получателя мошеннического платежа.

Для использования списков 550-П (639-П) необходимо в профиле обнаружения мошеннических платежей создать одно или несколько ручных правил, использующих критерии вида "ИНН плательщика из списка 550-П", "ИНН получателя из списка 550-П" и аналогичных. При этом возможна как остановка платежа, так и просто фиксация факта срабатывания правила - для этого необходимо выбрать соответствующее действие "остановить для проверки фин.мониторингом", "подозревать в краже средств" или "не останавливать платеж, но зафиксировать срабатывание правила".

Для импорта файла фида ФинЦЕРТ необходимо зайти в интерфейс "Аналитика по получателю", нажать на кнопку "Импорт черного списка получателей", а затем указать ZIP-файл, полученный от ФинЦЕРТ:

Рисунок 70. Кнопка для импорта черного списка получателей

Файл фида может быть импортирован также путем отправки почтового сообщения, содержащего ZIP-файл фида ФинЦЕРТ, на ящик fwblack@сервер_управления (аналогично обработки письма антидроп-клуба).

FraudWall может автоматически ежедневно подключаться к серверу ФинЦЕРТ через API, автоматически скачивать и обрабатывать файлы фидов.

Для настройки этого механизма необходимо:

Формирование конфигурации postfix осуществляется автоматически на основе данных о пользователях WWW-интерфейса системы (список SMTP-адресов пользователей и их права доступа), а также конфигурационного файла fraudwall.xml (IP адрес внешнего почтового сервера банка, на который будет отправляться все сообщения системы.

Каждый раз после изменения параметра mail_server в файле fraudwall.xml, а также создания (удаления) пользователей с ролью «Администратор» и изменения их SMTP-адресов, необходимо выполнить следующую команду: fw_control -s mail

Т.к. доставкой SMTP-сообщений занимается postfix, все события помещаются в файл журнала /var/log/maillog.

Apr 19 06:10:53 localhost postfix/pickup[4926]: E579F60556: uid=0 from=<>
Apr 19 06:10:53 localhost postfix/cleanup[7824]: E579F60556: message-id=<20120419061053.E579F60556@localhost.localdomain>
Apr 19 06:10:53 localhost postfix/qmgr[1331]: E579F60556: from=<>, size=2173, nrcpt=2 (queue active)
Apr 19 06:10:53 localhost postfix/smtp[7827]: connect to 192.168.1.158[192.168.1.158]:25: Connection refused
Apr 19 06:10:53 localhost postfix/smtp[7827]: E579F60556: to=<b@test.com>, relay=none, delay=0.01, delays=0.01/0/0/0, dsn=4.4.1, status=deferred (connect to 192.168.1.158[192.168.1.158]:25: Connection refused)
Apr 19 06:10:53 localhost postfix/smtp[7827]: E579F60556: to=<x@x.com>, relay=none, delay=0.01, delays=0.01/0/0/0, dsn=4.4.1, status=deferred (connect to 192.168.1.158[192.168.1.158]:25: Connection refused)

Дата/время в файле журнала событий фиксируются во временной зоне UTC.

В файле журнала событий, каждому почтовому сообщению присваивается уникальный идентификатор (в данном случае это E579F60556), по которому можно отследить историю доставки почтового сообщения.

В случае недоступности почтового сервера банка, все SMTP-сообщения помещаются в очередь. Максимальное время хранения одного письма в очереди - 1 сутки.

Почтовая система postfix автоматически пытается повторить доставку писем через каждые 3 минуты с момента времени неуспешной доставки.

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

Административные сообщения направляются всем пользователям WWW-интерфейса системы FraudWall с ролью «Администратор», у которых указан e-mail.

Это разделение сделано для того, чтобы уведомления о подозрительных платежных поручениях отправлялись сотрудникам соответствующего филиала.

Дамп трафика проверяется на наличие каких-либо проблем на серверах ДБО с периодом в 10 минут.

Система мониторинга автоматически проверяет - сколько HTTP-запросов в единицу времени обрабатывалось дольше допустимого времени. Если таких HTTP-запросов слишком много, то система автоматически формирует почтовый алерт на администраторов системы.

$email_options = "-t 09 18";

С помощью утилиты диагностики, поставляемой в комплекте FraudWall, можно также анализировать динамику возникновения проблем в системе ДБО за любой период времени (на основании архивов дампа трафика).

Утилита диагностики запускается командой fw_diagnose

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

Для обновления программного обеспечения операционной системы необходимо наличие со стороны компании RedHat действующей технической поддержки операционной системы RedHat Enterprise Linux уровня не ниже «Self-support Subscription». Если сотрудники банка имеют недостаточный опыт работы с операционной системе RedHat Linux, рекомендуется заключить техническую поддержку более высокого уровня («Standard Subscription» либо «Premium Subscription»).

Компания RedHat также предоставляет возможность получить бесплатную техническую поддержку на операционную систему уровня «Self-support Subscription» на ознакомительный период сроком на 1 месяц.

По умолчанию, установка обновлений на операционную систему осуществляется в ручном режиме.

Для обновления программного обеспечения операционной системы и FraudWall, необходимо в SSH-консоли вручную выполнить следующую команду: fw_update -s

Если на момент запуска указанной команды процедура обновления уже запущена в параллельном процессе, будет выведен соответствующий текст и работа команды будет прекращена. В этом случае необходимо подождать 5-10 минут и повторить еще раз:

Рисунок 73. Сообщение о уже запущенном процессе обновления

Если предыдущий запуск процедуры обновления завершился некорректно, запуск нового процесса обновления возможен не ранее, чем через 300 минут с момента предыдущего запуска.

Как правило, обновления на операционную систему не требуют перезагрузки и не вносят существенного изменения в работоспособность запущенных компонент системы FraudWall, поэтому их можно устанавливать в рабочее время.

Тем не менее, обновление некоторых системных компонент (например, glibc) приводит к сбросу параметров, используемых запущенными компонентами FraudWall, поэтому они перестают работать до полной перезагрузки операционной системы.

Обновления на операционную систему рекомендуется устанавливать во внерабочее время, но не не реже 1 раза в неделю.

Если в процессе обновления было обновлено ядро Linux (пакет kernel-…), то после завершения процесса обновлений необходимо перегрузить операционную систему командой: reboot

Если при этом сервер установлен на виртуальную машину VMWare, после перезагрузки необходимо дополнительно выполнить команду: vmware-config-tools.pl -m

Если в конфигурационном файле /etc/fraudwall/fraudwall.xml значение параметра autoupdate_rh задано как “on”, а autoupdate_fw не задано как “off”, то обновление операционной системы осуществляется автоматически, как только обновление доступно в репозитории.

Если установка обновления привела к сбросу параметров, используемых запущенными компонентами FraudWall, они завершают свою работу. В этом случае система мониторинга автоматически попытается перезапустить отказавший компонент, а затем (после нескольких попыток) выполнит перезагрузку операционной системы. После перезагрузки все сервисы FraudWall продолжат свою работу в обычном режиме.

Таким образом, ориентировочное время неработоспособности компонент не превысит 15 минут (это примерное время отказа сервиса, после которого система мониторинга отправит сервер на перезагрузку).

После установки обновлений на ядро Linux (пакет kernel-*), обновления не вступят в силу до тех пор, пока администратор системы вручную не перезагрузит сервер (см. раздел 10.3.2 «Установка обновлений на операционную систему в ручном режиме»).

Для обновления программного обеспечения FraudWall необходимо наличие действующей технической поддержки на систему FraudWall. Текущий срок окончания действия техподдержки можно посмотреть в WWW-интерфейсе системы FraudWall, пункт «о системе» меню «Помощь»:

По умолчанию, установка обновлений на систему FraudWall осуществляется в автоматическом режиме. Тем не менее, можно отключить режим автоматической установки обновлений на систему FraudWall, выставив значение параметра autoupdate_fw как “off”. При обнаружении нового доступного обновления, на почтовые ящики пользователей с ролью «администратор системы» формируется письмо с соответствующим текстом.

Обновление программного обеспечения системы FraudWall осуществляется вручную в SSH-консоли посредством выполнения следующей команды: fw_update

Если на момент запуска указанной команды процедура обновления уже запущена в параллельном процессе, будет выведен соответствующий текст и работа команды будет прекращена.

Если предыдущий запуск процедуры обновления завершился некорректно, запуск нового процесса обновления возможен не ранее, чем через 300 минут с момента предыдущего запуска.

Обновления программного обеспечения системы FraudWall готовятся с тем расчетом, чтобы они могли быть установлены на рабочую систему без существенного простоя (ориентировочный простой составит не более 2-3 секунд), поэтому рекомендуется не отключать автоматическое обновление компонент системы FraudWall.

Рекомендуется устанавливать обновления программного обеспечения системы FraudWall не реже, чем 1 раз в день.

Если в конфигурационном файле /etc/fraudwall/fraudwall.xml значение параметра autoupdate_fw не задано как “off” (т.е. выставлено значение “on”, либо данный параметр отсутствует), обновление программного обеспечения FraudWall осуществляется автоматически, как только обновление станет доступным в репозитории.

IP адрес сервера обновлений является одним из сетевых параметров операционной системы и указывается в процессе установки операционной системы (см.раздел 4.5 «Установка операционной системы») либо после (см.раздел 5.1.6 «Администрирование сетевых настроек»).

Инициировать процесс скачивания обновлений можно также вручную, выполнив на WWW-сервере обновлений команду: fw_update

После успешного получения обновлений, они становятся доступными для серверов с системой FraudWall.

Если взаимодействие с Интернет осуществляется через proxy-сервер, в конфигурационном файле /etc/yum.conf в секции [main] необходимо прописать IP адрес и порт proxy-сервера, а также добавить опцию http_caching=none, как показано ниже:

[main]
# в параметре proxy укажите IP адрес и порт подключения
# к proxy-серверу
proxy=http://192.168.1.1:3128
http_caching=none

При необходимости можно также указать логин и пароль для доступа к proxy-серверу (если авторизации на proxy-сервере нет, строки с proxy_username и proxy_password необходимо удалить!):

[main]
proxy=http://192.168.1.1:3128
proxy_username=USER
proxy_password=PASSWORD
http_caching=none

FraudWall является аналитической системой, которая для анализа получает следующую информацию:

В качестве основных данных для анализа выступает платеж, как до его исполнения в АБС, так и после.

Платежи после исполнения в АБС получаются посредством fraudwall_learn (см.11.3 «fraudwall_learn. Получение платежей, исполненных в АБС»).

Информация о платежах, еще не исполненных в АБС, может поступать из разных источников в зависимости от варианта интеграции:

FraudWall может одновременно получать и связывать информацию из нескольких источников данных. Например, один и тот же платеж может быть выявлен сначала в дампе трафика, затем он обнаружен в базе ДБО в VIEW fraudwall_doc, а затем он же обнаружен в базе АБС в таблице fraudwall_alert - для этого одного платежа FraudWall построит и отобразит в интерфейсе цепочку прохождения в разных системах банка.

При этом на всех этапах проверки платежа учитываются особенности, которые есть только на предыдущих этапах. Например, в АБС нет информации об IP адресе, с которого был создан платеж, поэтому при анализе платежа в fraudwall_alert такой информации нет. Но, т.к. до появления платежа в АБС FraudWall еще увидел этот же платеж в базе ДБО (или дампе трафика), в котором информация об IP адресе есть, при анализе платежа в АБС информация об IP адресе будет также учтена.

В качестве вспомогательных данных могут выступать:

Вспомогательные данные не являются обязательными для принятия решения об остановке платежа - они позволяют только улучшить характеристики обнаружения платежей. Если их нет, по платежу все равно будет принято решение, является ли платеж подозрительным или нет.

Результатом работы FraudWall является:

На этапе ознакомительного тестирования системы торможение платежей не требуется - по сути, сервер FraudWall стоит "в стороне" от существующих информационных систем банка и просто читает информацию из их баз данных. При этом, даже если платеж вызвал подозрение в системе FraudWall, он обрабатывается точно также как и до подключения системы FraudWall (т.е. из ДБО выгружается в АБС и исполняется).

FraudWall может быть подключен как к базе ДБО, так и к базе АБС, а также одновременно и к базе ДБО, и к АБС.

При подключении к анализируемым базам данных большого объема, FraudWall может вызвать дополнительную нагрузку на сервер баз данных. Если в банке существует репликационный сервер анализируемой базы данных, содержащий те же данные, что и на основном, возможно настроить FraudWall так, чтобы он "тяжелые" запросы формировал на репликационный сервер, а на основной сервер баз данных отправлялись только "легкие" запросы.

Для этого необходимо создать дополнительный сайт с типом "Обучение антифрода платежам из базы данных", указать в нем подключение к репликационному серверу базы данных, а также в параметре "Анализируемые платежи считать созданными в сайте..." указать сайт FraudWall, который занимается анализом платежей.

В данном варианте FraudWall периодически опрашивает базу данных ДБО или АБС на предмет появления новых платежей.

Работа с базой данных осуществляется в режиме "только на чтение", что исключает какие-либо проблемы с работоспособностью ДБО или АБС. Платеж, даже если он вызвал подозрение, в ДБО не останавливается, и выгружается в АБС штатными механизмами.

Остановка подозрительных платежей осуществляется в системе АБС, для этого FraudWall выгружает реквизиты подозрительного платежа в таблицу fraudwall_alert. Задача АБС заключается в том, чтобы запретить исполнение платежных документов, реквизиты которых находятся в таблице fraudwall_alert, не имеющих статус "можно исполнять".

Рисунок 76. Упрощенная схема интеграции на уровне анализа платежей в базе данных

11.2.1.2. Настройка на стороне FraudWall

Работы по настройке FraudWall необходимо начинать только после того, как были выполнены работы на стороне сервера анализируемой базы данных.

Подключение к анализируемой базе данных осуществляется посредством ODBC-драйверов, которые устанавливаются на сервере управления FraudWall (см. раздел 12.4 «Установка ODBC-драйверов»).

После проверки работоспособности ODBC-драйверов, необходимо открыть WWW-интерфейс администрирования системы, пункт «Сайты» меню «Система», и создать новый сайт с типом «Анализ платежей во VIEW fraudwall_doc»:

Рисунок 77. Тип Web-сайта, который используется для подключения к базе данных ДБО

В вкладке «Анализируемая база данных» необходимо указать параметры подключения к анализируемой базе данных:

Рисунок 78. Параметры для подключения к анализируемой базе данных

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

Журнал событий анализатора платежей из базы данных ДБО находится в файле /var/log/fraudwall/siteXXX-afdb.log, где XXX - ID созданного сайта.

При обнаружении ошибок в анализируемой базе данных (например, отсутствие прав доступа, некорректный набор полей в VIEW и т.д.), пользователю с ролью "Администратор" формируется почтовое уведомление с описанием текста ошибки.

В таком варианте интеграции система ДБО или АБС помещает реквизиты платежа для анализа в таблицу fraudwall_alert с значением поля status, равным X или J. FraudWall же, в свою очередь, периодически ищет в этой таблице записи с данными значениями поля status, анализирует найденные платежи, а затем обновляет это поле согласно результата анализа (т.е. можно или нет исполнять в АБС данный платеж).

11.2.2.1. Настройка на стороне FraudWall

Работы по настройке FraudWall необходимо начинать только после того, как были выполнены работы на стороне анализируемой системы банка: создана таблица fraudwall_alert, а сама система банка умеет выгружать в нее платежи для анализа.

В интерфейсе FraudWall необходимо открыть пункт «Сайты» меню «Система», выбрать в выпадающем списке «Создать новый сайт». В графе «Тип сайта FraudWall» вкладки «Общие параметры» из выпадающего списка выбрать «Анализ платежей из таблицы fraudwall_alert».

Рисунок 79. Создание нового сайта

После необходимо указать, в какой базе данных создана таблица fraudwall_alert. Для этого во вкладке «Анализируемая база данных» необходимо указать параметры созданного подключения, как показано на рисунке.

Рисунок 80. Выбор анализируемой базы данных

FraudWall начнет анализ таблицы fraudwall_alert сразу же после сохранения настроек.

Журнал событий анализа платежей из таблицы fraudwall_alert находится в файле /var/log/fraudwall/siteNNN-afdb.log.

В данном варианте интеграции система ДБО или АБС сама передает реквизиты платежа для анализа, а FraudWall, в свою очередь, сразу возвращает результат проверки данного платежа. В этом случае система ДБО не будет выгружать подозрительный платеж в АБС до тех пор, пока по данному платежу не будет получено подтверждение клиента.

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

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

Например, если в процессе анализа трафика фиксируется, что сервер на запрос клиента возвращает ошибку, весьма вероятна ситуация, что данный запрос был сформирован троянской программой, которая не учитывает особенности настройки конкретного сервера ДБО. Если же с сервером «в ручном режиме» работает непосредственно клиент, возникновение ошибки маловероятно.

Дамп трафика снимается на стороне банка модулем hGuard системы FraudWall. Снятый дамп записывается в файл, который в дальнейшем анализируется системой FraudWall в online-режиме.

Размер файла дампа трафика получается небольшим, т.к. в него записывается только динамический контент, а статический (картинки, html-страницы и т.д.) в файл дампа не помещаются.

Параметры интеграции с системой ДБО задаются посредством пункта «Сайты» в меню «Система», вкладка «WWW-сервер ДБО»:

Рисунок 81. Параметры интеграции с ДБО на уровне анализа дампа трафика

11.2.4.2. Интеграция в проксированном режиме

В типовом сценарии интеграции системы FraudWall с внутренним WWW-сервером (в т.ч. являющимся сервером системы ДБО) предполагается, что клиент первоначально соединяется с модулем hGuard, где осуществляется проверка данных запроса клиента на допустимость. В случае, если запрос допустим согласно правил фильтрации, он передается на защищаемый WWW-сервер в прокси-режиме. Информация о IP-адресе клиента, SSL-характеристик установки HTTPS-соединения передается на защищаемый WWW-сервер как дополнительные HTTP-теги.

Рисунок 82. Упрощенная схема интеграции в проксированном режиме

Недостатком такой схемы интеграции FraudWall с системой ДБО является то, что на WWW-сервере в качестве IP адреса клиента будет выступать IP-адрес сервера системы FraudWall.

Поэтому, модуль фильтрации трафика FraudWall передает информацию об оригинальном IP адресе клиента в HTTP-заголовке X-hGuard-ClientIP каждого HTTP-запроса, передаваемого на WWW-сервер ДБО. Если для системы ДБО важна информация об IP адресе клиента, программное обеспечение ДБО должно использовать значение из этого HTTP-заголовка вместо IP адреса, с которого было соединение с WWW-сервером системы ДБО.

Назначение:

Данный запрос проверяет, поддерживает ли поле updated структуры fraudwall_learn время с точностью до минут или секунд (если нет, то возвращаемое время всегда 00:00:00). Запрос выполняется однократно, если ранее такой информации не было.

Когда выполняется запрос:

Однократно при запуске процесса FraudWall (если ранее не было установлено, что updated поддерживает минуты и секунды).

Входные параметры для запроса:

updated >= текущие сутки 00:00:00 И docdate >= текущие сутки 00:00:00 

Если структура поддерживает abs_date, то дополнительно в запросе указывается:

И abs_date >= текущие сутки 00:00:00

Результат выполнения запроса:

Возвращает от 1 до максимум 10 значений updated, соответствующих исполненным платежам за текущие сутки. Если хотя бы одно из полученных значений updated содержит минуты или секунды, значит, поле updated их поддерживает.

Назначение:

Данный запрос получает реквизиты платежей, которые сегодня были исполнены в АБС.

Когда выполняется запрос:

При выполнении хотя бы одного запроса, FraudWall оценивает время, которое он выполнялся внешней системой - если запрос выполняется более 15 секунд, он считается тяжелым.

Если в свойствах сайта значение параметра "Проверка работоспособности механизма АБС блокировки подозрительных документов" не в значении "отсутствует", FraudWall будет делать запрос загрузки платежей, исполненных за текущий день, каждые 10 минут, вне зависимости от того, является запрос тяжелым или нет.

Если этот параметр стоит в значении "отсутствует", запрос получения исполненных платежей за текущий день делается только если в свойствах сайта значение параметра "Реквизиты исполненных (даже не вызывавших подозрения) платежей хранить" выставлено от 1 и более дней. При этом учитывается также, является ли запрос тяжелым или нет - если запрос тяжелый (т.е. выполняется долго), он запускается однократно ночью, если не тяжелый - то каждые 15 минут.

Входные параметры для запроса:

updated <= текущие сутки 23:59:59

Если поле updated поддерживает минуты и секунды (см. 11.3.2 «Проверка, поддерживает ли поле UPDATED часы, минуты и секунды»), то также указывается

И updated >= максимальное время updated текущих суток, полученное при предыдущем запросе

Если же updated возвращает только дату (без времени), то указывается

И updated >= текущие сутки 00:00:00

Если структура поддерживает abs_date, то:

И abs_date >= текущие сутки 00:00:00
И abs_date <= текущие сутки 23:59:59

Если структура не поддерживает abs_date, то:

И docdate >= текущие сутки 00:00:00 минус 14 суток
И docdate <= текущие сутки 23:59:59

Результат выполнения запроса:

Возвращает массив структур fraudwall_learn, соответствующий всем исполненным в АБС платежам согласно заданным критериям отбора.

Если updated поддерживает минуты и секунды, результат дополнительно должен быть отсортирован по возрастанию значения updated

Назначение:

Данный запрос получает реквизиты платежей, которые были исполнены в АБС за заданные сутки.

Когда выполняется запрос:

Получение платежей за предыдущие дни выполняется в следующих случаях:

При выполнении хотя бы одного запроса, FraudWall оценивает время, которое он выполнялся внешней системой - если запрос выполняется более 15 секунд, он считается тяжелым.

Процесс получения платежей за предыдущие дни запускается с учетом того, является запрос тяжелым или нет. Если запрос тяжелый (т.е. выполняется долго), то он вызывается в ночное время, если нет - то он может быть вызван и днем (но не чаще, чем 1 раз в 1 минуту).

Входные параметры для запроса:

FraudWall всегда запрашивает данные максимум за одни сутки (т.е. за заданную дату)

updated <= заданная дата 23:59:59

Если поле updated поддерживает минуты и секунды (см. 11.3.2 «Проверка, поддерживает ли поле UPDATED часы, минуты и секунды»), то:

И updated >= заданная дата с максимальным временем, полученным при предыдущем запросе

Если же updated возвращает только дату (без времени), то:

И updated >= заданная дата 00:00:00

Если структура поддерживает abs_date, то:

И abs_date >= заданная дата 00:00:00
И abs_date <= заданная дата 23:59:59

Если структура не поддерживает abs_date, то:

И docdate >= заданная дата 00:00:00 минус 14 суток
И docdate <= заданная дата 23:59:59

Результат выполнения запроса:

Возвращает массив структур fraudwall_learn, соответствующий всем исполненным в АБС платежам согласно заданным критериям отбора.

Если updated поддерживает минуты и секунды, результат дополнительно должен быть отсортирован по возрастанию значения updated

Назначение:

Данный запрос получает перечень ID клиентов с наименьшими ID. В дальнейшем по этому перечню будут загружаться данные по клиенту из анализируемой системы.

Когда выполняется запрос:

Раз в сутки

Входные параметры для запроса:

Отсутствуют

Результат выполнения запроса:

Возвращает первые 10000 значений id, отсортированные по возрастанию (т.е. 10000 значений с наименьшими id клиента).

Назначение:

Данный запрос получает очередной перечень ID клиентов в цикле загрузки информации по всем клиентам.

Когда выполняется запрос:

По завершению обработки предыдущего списка id клиентов.

Входные параметры для запроса:

id = ID последнего обработанного клиента

Результат выполнения запроса:

Возвращает первые 10000 значений id больших заданного значения, отсортированные по возрастанию (т.е. 10000 следующих значений после заданного значения).

Назначение:

Данный запрос получает структуру данных fraudwall_client для заданного клиента.

Когда выполняется запрос:

По каждому клиенту из перечня ID клиентов (см. 11.4.3 «Получение перечня последующих ID клиентов »).

Входные параметры для запроса:

id = ID клиента

Результат выполнения запроса:

Возвращает структуру fraudwall_client, соответствующую заданному id клиента в анализируемой системе.

Назначение:

Данный запрос получает остаток на счете (в валюте счета и в рублевом эквиваленте).

Когда выполняется запрос:

В момент проверки платежа (но не чаще, чем 1 раз в 20 секунд).

Входные параметры для запроса:

account = р/с (плательщика из реквизитов платежа)
И bic = БИК банка (плательщика из реквизитов платежа)
И id = ID плательщика (владельца счета)
И (date_close IS NULL ИЛИ date_close > вчера)

Если структура поддерживает time_when, то дополнительно в запросе указывается:

И time_when >= текущее время минус 3 суток

Результат выполнения запроса:

Возвращает одну структуру (при наличии поля time_when - массив структур, отсортированных по уменьшению time_when), соответствующих запрашиваемым критериям.

Назначение:

Данный запрос получает перечень счетов и остатков на них для заданного клиента.

Когда выполняется запрос:

После вызова запроса на получение структуры fraudwall_client для заданного клиента (см. 11.4.4 «Получение информации о заданном клиенте»)

Входные параметры для запроса:

id = ID клиента
И (date_close IS NULL или date_close > сейчас минус 14 суток)

Если структура поддерживает time_when, то дополнительно в запросе указывается:

И (time_when IS NULL или time_when > текущее время минус 3 суток)

Результат выполнения запроса:

Возвращает массив структур fraudwall_balance, соответствующий всем счетам клиента согласно заданным критериям отбора, отсортированный в следующем порядке:

Назначение:

Данный запрос получает контактную информацию о клиенте (его телефоны, адреса, ФИО и должности представителей и т.д.).

Когда выполняется запрос:

Входные параметры для запроса:

id = ID клиента банка

Результат выполнения запроса:

Возвращает одну или массив структур fraudwall_contact, соответствующих запрашиваемым критериям. Порядок возвращаемых данных неважен.

Назначение:

Данный запрос получает контактную информацию о клиенте (его телефоны, адреса, ФИО и должности представителей и т.д.).

Когда выполняется запрос:

Входные параметры для запроса:

inn = ИНН клиента банка

Результат выполнения запроса:

Возвращает одну или массив структур fraudwall_contact, соответствующих запрашиваемым критериям. Порядок возвращаемых данных неважен.

Назначение:

Данный запрос получает контактную информацию о создателе платежа (его телефоны, адреса, ФИО и должности представителей и т.д.).

Когда выполняется запрос:

Входные параметры для запроса:

docid = ID платежного документа

Результат выполнения запроса:

Возвращает одну или массив структур fraudwall_contact_doc, соответствующих запрашиваемым критериям, отсортированных по убыванию значения поля time_when.

Назначение:

Данный запрос получает перечень ID клиентов, которые связаны с данным ID клиента.

Когда выполняется запрос:

Данный запрос выполняется после вызова запроса на получение структуры fraudwall_client для заданного клиента (см. 11.4.4 «Получение информации о заданном клиенте»).

Входные параметры для запроса:

id = ID клиента банка

Результат выполнения запроса:

Возвращает одну или массив структур fraudwall_clientref, соответствующих запрашиваемым критериям. Порядок возвращаемых данных неважен.

Каждой записи в таблице fraudwall_alert соответствует статус, который может принимать одно из следующих значений:

Назначение:

Данный запрос получает перечень платежей, подлежащих анализу системой FraudWall (только в режиме интеграции, основанной на анализа платежей в таблице fraudwall_alert).

Когда выполняется запрос:

Запрос выполняется только если в свойствах сайта указан режим "анализ платежей в таблице fraudwall_alert".

Период опроса указывается в свойствах сайта в параметре "Периодичность поиска платежей в базе данных" и составляет обычно раз в 5-30 секунд.

Если предыдущий результат выполнения запроса содержал один или более платеж для анализа, следующий запрос будет с задержкой 0,1 секунды.

Входные параметры для запроса:

status = 'X' ИЛИ (status = 'J' И docid IS NULL)

Если fraudwall_alert содержит dboid (а не absid), то:

И dboid IS NOT NULL

Если fraudwall_alert содержит absid (а не dboid), то:

И absid IS NOT NULL

Результат выполнения запроса:

Возвращает одну или массив структур fraudwall_alert, содержащих перечень платежей для проверки системой FraudWall, отсортированных последовательно по полям amount, docnumber, docdate, purpose, updated.

Назначение:

Данный запрос выгружает в таблицу fraudwall_alert реквизита платежа вместе с полем status, соответствующего результату проверки платежа в FraudWall (только в режиме интеграции, основанной на анализа платежей в VIEW fraudwall_doc или при анализе трафика).

Когда выполняется запрос:

Запрос выполняется только если в свойствах сайта указан режим "анализ платежей в VIEW fraudwall_doc" либо "анализ трафика".

Событие, по которому осуществляется выгрузка платежей в таблицу fraudwall_alert, зависит от свойства сайта "Какие платежи выгружать в базу данных АБС" - либо только подозрительные, либо все (подозрительные и неподозрительные).

Если платеж подлежит выгрузке, он выгружается в таблицу fraudwall_alert сразу после его обнаружения в VIEW fraudwall_doc или в трафике.

Входные параметры для запроса:

значение полей docid, siteid, updated, docnumber, docdate, from_name, from_inn, from_account, from_bic, from_city, from_bank, to_name, to_inn, to_account, to_bic, to_city, to_bank, purpose, amount, status

Результат выполнения запроса:

Добавляет одну запись в таблицу fraudwall_alert, содержащую указанные поля.

Назначение:

Обновляет значение поля status таблицы fraudwall_alert после проверки платежа

Когда выполняется запрос:

Сразу после проверки платежа системой FraudWall.

Входные параметры для запроса:

status = новый статус

Если fraudwall_alert содержит dboid (а не absid), то:

ЕСЛИ dboid=ID документа в ДБО

Если fraudwall_alert содержит absid (а не dboid), то:

ЕСЛИ absid=ID документа в АБС

Результат выполнения запроса:

В таблице fraudwall_alert для записи с заданными критериями отбора значение поля status выставлено как заданное значение, поле updated выставлено как текущее время на стороне сервера баз данных.

Назначение:

Обновляет значение поля status таблицы fraudwall_alert после изменения статуса платежа в интерфейсе FraudWall

Когда выполняется запрос:

Сразу после изменения статуса платежа в интерфейсе FraudWall.

Входные параметры для запроса:

status = новый статус
reason = комментарий, указанный в интерфейсе FraudWall
showtext = текст
ЕСЛИ docid=ID документа в FraudWall

В таблице fraudwall_alert для записи с заданными критериями отбора значение поле updated выставлено как текущее время на стороне сервера баз данных, полей status, reason и showtext выставлены в соответствии со входными параметрами.

Назначение:

В режиме анализа платежей в таблице fraudwall_alert выставляет значение docid проверяемой записи

Когда выполняется запрос:

Сразу после проверки платежа.

Входные параметры для запроса:

docid = ID документа в FraudWall

Если fraudwall_alert содержит dboid (а не absid), то:

ЕСЛИ dboid=ID документа в ДБО

Если fraudwall_alert содержит absid (а не dboid), то:

ЕСЛИ absid=ID документа в АБС

Результат выполнения запроса:

Обновлено значение поля docid в таблице fraudwall_alert для документа с заданными критериями отбора

Назначение:

Если в таблице fraudwall_alert создано опциональное поле showtext, в него выгружается либо перечень сработавших правил, либо краткий комментарий-инструкция для сотрудника банка.

Когда выполняется запрос:

Сразу после проверки платежа или изменения статуса по платежу в интерфейсе FraudWall.

Входные параметры для запроса:

showtext = текст

Если fraudwall_alert содержит dboid (а не absid), то:

ЕСЛИ dboid=ID документа в ДБО

Если fraudwall_alert содержит absid (а не dboid), то:

ЕСЛИ absid=ID документа в АБС

Результат выполнения запроса:

Обновлено значение поля showtext в таблице fraudwall_alert для документа с заданными критериями отбора

Назначение:

Если в АБС реализована возможность выставления статуса платежу, вызвавшему подозрение, FraudWall может импортировать данный статус.

Когда выполняется запрос:

Примерно раз в 5 минут.

Входные параметры для запроса:

status = импортируемый статус (одно из значений F, G, R, J)

Результат выполнения запроса:

Возвращает значение одно или несколько значений docid (ID документа в FraudWall), соответствующих искомому статусу

Назначение:

Если есть документы для импорта статуса (см. 11.9.10 «Получение списка документов для импорта из fraudwall_alert статуса, выставленного АБС» ), FraudWall по каждому документу получает статус и комментарий, выставленный со стороны АБС

Когда выполняется запрос:

Для каждого документа, статус которого необходимо импортировать

Входные параметры для запроса:

docid = ID документа в FraudWall

Результат выполнения запроса:

Возвращает значение status и reason, соответствующих критериям поиска

Назначение:

Данный запрос получает перечень событий, происходивших в системе ДБО с заданного момента времени

Когда выполняется запрос:

Периодически (примерно 1 раз в 1 секунду).

Входные параметры для запроса:

time_when >= максимальное время последней записи, полученное в предыдущем запросе

При первом запуске процесса запрашиваются события, которые произошли не ранее, чем 14 суток от текущего времени. Но в дальнейшем запрашиваются только события, которые происходили за последние 1-2 секунды.

Результат выполнения запроса:

Возвращает одну или массив структур fraudwall_dbolog, соответствующих запрашиваемым критериям, отсортированный по возрастанию time_when