Система FraudWall. Руководство администратора

Дата последней редакции документа: 27.01.2020

Открыть документацию в виде одной HTML-страницы

Открыть документацию в виде многостраничного документа


Содержание

1. Введение
2. Общие принципы работы системы FraudWall
3. Архитектура системы
3.1. Модули системы
3.1.1. FraudWall. Интерфейс системы
3.1.2. hGuard. Модуль фильтрации HTTP-трафика
3.1.3. Модуль FraudWall. Анализатор трафика
3.1.4. Удостоверяющий центр системы FraudWall
3.1.5. Управляющий WWW-сервер системы FraudWall
3.1.6. Исполнительный WWW-сервер системы FraudWall
3.1.7. Модуль управления системы FraudWall
3.2. Прочее программное обеспечение
3.2.1. Система мониторинга работоспособности
3.2.2. Сервер Memcached
3.2.3. Сервер баз данных PostgreSQL
3.3. Схема взаимодействия компонент системы FraudWall
4. Установка системы FraudWall
4.1. Общее описание
4.2. Определение архитектуры установки компонент системы FraudWall
4.2.1. Подход к тестированию системы FraudWall
4.2.2. Балансировка нагрузки между серверами FraudWall
4.3. Требования к аппаратному обеспечению
4.4. Получение дистрибутивов программного обеспечения
4.4.1. Получение дистрибутива RedHat Enterprise Linux
4.4.2. Получение дистрибутива CentOS
4.4.3. Получение дистрибутива Sun Java JRE
4.5. Установка операционной системы
4.6. Установка сервера базы данных системы FraudWall
4.7. Установка сервера управления системы FraudWall
4.8. Установка сервера анализа трафика
4.8.1. Установка модуля BSI на сервер FraudWall (предварительный этап)
4.8.2. Установка модуля BSI на сервер FraudWall (завершающий этап)
4.8.3. Действия при обновлении файлов сайта ДБО BS-Client
4.9. Установка WWW-сервера обновлений
4.10. Инфраструктура FraudNET
4.10.1. Общее описание
4.10.2. Синхронизация серверов
4.10.3. Настройка серверов для работы в режиме FraudNET
4.10.4. Работа с интерфейсом главного сервера управления
4.11. Сервис FraudTrack
4.11.1. Общее описание
4.11.2. Схема работы сервиса FraudTrack
4.11.3. Конфигурирование сервиса FraudTrack
4.11.4. Конфигурирование межсетевого экрана для работы сервиса FraudTrack
4.11.5. Особенности интеграции с IBM Trusteer Pinpoint Malware Detection
4.11.6. Особенности интеграции с Group-IB Bot-Trek Secure Bank
4.11.7. Особенности интеграции с Kaspersky Fraud Prevention Cloud
4.12. Система FraudInform
4.12.1. Общее описание
4.12.2. Установка системы FraudInform
4.12.3. Установка системы VoiceNavigator
4.12.4. Настройка соединения с VoiceNavigator
4.12.5. Настройка соединения с ATC Банка
4.12.6. Настройка правил набора номера телефона
4.12.7. Настройка специфичных для банка параметров
4.12.8. Настройка диалога общения с клиентом
4.12.9. Конфигурирование системы FraudInform
4.12.10. Диагностика работоспособности компонент
4.12.11. Запись разговоров системы
5. Администрирование системы FraudWall
5.1. Администрирование операционной системы
5.1.1. Общие положения
5.1.2. Администрирование через SSH-консоль
5.1.3. Интерфейс передачи файлов посредством протоколов SCP и SFTP
5.1.4. Интерфейс передачи файлов посредством сетевых дисков сети Microsoft
5.1.5. Пользователи операционной системы
5.1.6. Администрирование сетевых настроек
5.1.7. Конфигурирование межсетевых экранов
5.1.8. Подсистема журналирования
5.1.9. Регламентные процедуры
5.2. Администрирование системы FraudWall
5.2.1. Общие положения
5.2.2. Конфигурационный файл fwcontrol.xml
5.2.3. Конфигурационный файл fraudwall.xml
5.2.4. Администрирование пользователей системы FraudWall
5.2.5. Интеграция с ActiveDirectory
5.2.6. Сброс пароля встроенного администратора системы FraudWall
5.2.7. Аудит пользователей системы FraudWall
5.2.8. Конфигурирование профилей обнаружения мошеннических платежей
5.2.9. Конфигурирование системы FraudWall. Банки и филиалы
5.2.10. Конфигурирование системы FraudWall. Сайты
5.2.11. Кеширование трафика на стороне FraudWall
5.2.12. Балансировка нагрузки между WWW-серверами ДБО
5.2.13. Высвобождение лицензии в случае закрытия клиентом расчетного счета в банке
5.2.14. Решение проблем с базой данных
5.2.15. Очищение базы данных FraudWall
5.3. Архивирование и восстановление из архива
5.3.1. Общие положения
5.3.2. Создание архивной копии с помощью утилиты fw_backup в интерактивном режиме
5.3.3. Создание архивной копии с помощью утилиты fw_backup как cron-задание
5.3.4. Восстановление из архивной копии с помощью утилиты fw_restore
5.3.5. Восстановление из snapshot-образов и посекторной копии жесткого диска
5.3.6. Миграция сервера FraudWall на другой физический сервер.
5.4. Создание отказоустойчивой конфигурации
5.4.1. Общие положения
5.4.2. Создание резервного сервера
5.4.3. Порядок действий в случае сбоя основного сервера
5.4.4. Порядок действий при восстановлении отказавшего сервера
5.4.5. Переконфигурирование резервного сервера
6. Обнаружение мошеннических платежей
6.1. Общие принципы обнаружения мошеннических платежей
6.2. Конфигурирование правил и критериев обнаружения мошеннических платежей
6.2.1. Использование встроенных правил обнаружения мошеннических платежей
6.2.2. Создание собственных правил обнаружения мошеннических платежей
6.2.3. Особенности конфигурирования правил при неизвестных значениях флагов
6.3. Тестирование обнаружения мошеннических платежей
6.4. Тонкая настройка обнаружения мошеннических платежей
6.4.1. Снижение уровня ложного срабатывания системы
6.4.2. Повышение вероятности обнаружения мошеннических платежей
6.4.3. Использование утилиты fw_forecast
6.5. Анализ дампов трафика клиентов в ручном режиме
6.5.1. Подготовка файлов для обработки
6.5.2. Фильтрация сессий для извлечения из архива
6.5.3. Запуск утилиты формирования файлов дампов сессий клиентов
7. Обучение системы
7.1. Самообучение системы
7.2. Обучение через ODBC-подключение к базе данных ДБО
7.3. Обучение на основании файла экспорта
7.3.1. Формат файла для обучения из внешних источников
7.3.2. Использование утилиты обучения статистических профилей клиентов
7.4. Ведение черных и белых списков получателей
7.4.1. Ведение черных и белых списков получателей в ручном режиме
7.5. Ручной ввод данных о мошенническом платеже
7.6. Поддержка межбанковского почтового обмена ("антидроп-клуб")
7.6.1. Автоматическая обработка входящих почтовых сообщений
7.6.2. Ручная загрузка Excel-файла через WWW-интерфейс FraudWall
7.6.3. Формирование Excel-файла, используемого при обмене в рамках "антидроп-клуба"
7.7. Интеграция с системой FraudMonitor
7.8. Импорт списков по 550-П (639-П)
7.8.1. Использование списков 550-П (639-П)
7.9. Импорт файлов фидов ФинЦЕРТ
7.9.1. Импорт файла фида ФинЦЕРТ через Web-интерфейс FraudWall
7.9.2. Импорт файла фида ФинЦЕРТ через почтовое сообщение
7.9.3. Автоматическая загрузка фидов через API ФинЦЕРТ
8. Информирование о событиях в системе
8.1. Информирование по SMTP-почте
8.1.1. Формирование конфигурации postfix
8.1.2. Журнал событий доставки SMTP-сообщений
8.1.3. Повторная отправка почты
8.1.4. Особенности доставки административных SMTP-сообщений
8.1.5. Особенности доставки SMTP-сообщений при обнаружении подозрительного платежного поручения
9. Мониторинг и самовосстановление системы
9.1. Общие принципы
9.2. Журнал событий системы мониторинга
9.3. WWW-интерфейс системы мониторинга
9.4. Мониторинг серверов ДБО
9.4.1. Автоматическая диагностика проблем в ДБО
9.4.2. Диагностика проблем с ДБО в ручном режиме
10. Обновление программного обеспечения
10.1. Общие принципы
10.2. Информирование о необходимости установки обновлений
10.3. Обновление программного обеспечения операционной системы
10.3.1. Техническая поддержка на RedHat Enterprise Linux
10.3.2. Установка обновлений на операционную систему в ручном режиме
10.3.3. Установка обновлений на операционную систему в автоматическом режиме
10.4. Обновление программного обеспечения системы FraudWall
10.4.1. Техническая поддержка на систему FraudWall
10.4.2. Установка обновлений на систему FraudWall в ручном режиме
10.4.3. Установка обновлений на систему FraudWall в автоматическом режиме
10.5. Механизм получения обновлений
10.5.1. Использование централизованного WWW-сервера обновлений
10.5.2. Конфигурирование получения обновлений в проксированном режиме
11. Интеграция FraudWall с информационными системами банка
11.1. Общее описание интеграции
11.1.1. С какими системами банка и для каких целей требуется интеграция
11.1.2. Остановка подозрительных платежей
11.1.3. Типовой подход к интеграции на этапе тестирования системы
11.1.4. Снижение нагрузки на сервер анализируемой базы данных
11.2. Варианты интеграции FraudWall с системами банка
11.2.1. Анализ платежей из VIEW fraudwall_doc
11.2.2. Анализ платежей из таблицы fraudwall_alert (по принципу "вопрос - ответ")
11.2.3. Анализ платежей по HTTP/HTTPS-запросу (по принципу "вопрос - ответ")
11.2.4. Анализ WWW-трафика
11.3. fraudwall_learn. Получение платежей, исполненных в АБС
11.3.1. Описание полей структуры fraudwall_learn
11.3.2. Проверка, поддерживает ли поле UPDATED часы, минуты и секунды
11.3.3. Получение реквизитов платежей, исполненных в АБС за текущий день
11.3.4. Получение реквизитов платежей, исполненных в АБС, за предыдущие дни
11.4. fraudwall_client. Получение информации о клиентах банка
11.4.1. Описание полей структуры fraudwall_client
11.4.2. Первоначальное получение перечня ID клиентов для загрузки
11.4.3. Получение перечня последующих ID клиентов
11.4.4. Получение информации о заданном клиенте
11.5. fraudwall_balance. Получение счетов клиента и суммы остатка на них
11.5.1. Описание полей структуры fraudwall_balance
11.5.2. Получение остатка на заданном счете
11.5.3. Получение информации о всех счетах заданного клиента
11.6. fraudwall_contact. Получение контактной информации о клиенте
11.6.1. Описание полей структуры fraudwall_contact
11.6.2. Получение контактов клиента на основе его ID
11.6.3. Получение контактов клиента на основе его ИНН
11.7. fraudwall_contact_doc. Получение контактной информации о создателе платежа
11.7.1. Описание полей структуры fraudwall_contact_doc
11.7.2. Получение контактов клиента на основе ID документа
11.8. fraudwall_clientref. Получение информации о связях клиента банка
11.8.1. Описание полей структуры fraudwall_clientref
11.8.2. Получение связей заданного клиента
11.9. fraudwall_alert. Получение и выгрузка результатов проверки платежей
11.9.1. Статусы платежа
11.9.2. Рекомендации по созданию таблицы fraudwall_alert
11.9.3. Описание полей таблицы fraudwall_alert
11.9.4. Получение платежей для анализа
11.9.5. Выгрузка платежа со статусом проверки
11.9.6. Обновление статуса платежа в таблице fraudwall_alert на основе ID документа в АБС или ДБО
11.9.7. Обновление статуса платежа в таблице fraudwall_alert на основе ID документа в FraudWall
11.9.8. Обновление значения docid платежа в таблице fraudwall_alert
11.9.9. Обновление значения showtext платежа в таблице fraudwall_alert
11.9.10. Получение списка документов для импорта из fraudwall_alert статуса, выставленного АБС
11.9.11. Импорт статуса и комментария из fraudwall_alert, выставленного АБС
11.10. fraudwall_dbolog. Получение журнала событий системы ДБО
11.10.1. Описание полей структуры fraudwall_dbolog
11.10.2. Получение новых событий работы клиента
11.11. fraudwall_doc. Получение платежей для анализа
11.11.1. Описание полей структуры fraudwall_doc
11.11.2. Получение платежей для проверки из VIEW fraudwall_doc
11.12. fraudwall_alert_client. Получение и выгрузка подозрительных клиентов банка
11.12.1. Описание полей структуры fraudwall_alert_client
11.12.2. Импорт списка клиентов, которым запрещена работа в ДБО
11.12.3. Получение актуального статуса клиента
11.12.4. Блокирование клиенту работы в ДБО
11.12.5. Разблокирование клиенту работы в ДБО
12. Приложения
12.1. Процедура регистрации операционной системы RedHat Enterprise Linux
12.2. Процедура экспорта SSL-сертификата из IIS
12.3. Формирование bsi.xml в формате Linux
12.4. Установка ODBC-драйверов
12.4.1. Установка ODBC-драйверов для Oracle
12.4.2. Установка ODBC-драйверов для Microsoft SQL Server и Sybase
12.4.3. Установка ODBC-драйверов для PostgreSQL
12.4.4. Установка ODBC-драйверов для Firebird
12.4.5. Установка ODBC-драйверов для Progress OpenEdge
12.4.6. Установка ODBC-драйверов для Pervasive SQL
12.4.7. Установка ODBC-драйверов для H2
12.4.8. Установка ODBC-драйверов для MySQL
12.4.9. Редактирование конфигурационного файла /etc/odbc.ini
12.4.10. Диагностика и решение проблем с ODBC-драйверами
Термины и определения

1. Введение

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

  • система ДБО (предотвращение кражи средств клиента банка, являющейся следствием атак на компьютер клиента банка)

  • система АБС (предотвращение кражи средств клиента, являющейся следствием злонамеренного действия среди сотрудников банка)

  • АРМ КБР (предотвращение кражи средств банка, являющейся следствием атак на АРМ КБР)

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

  • анализ подозрительных действий пользователя в текущей сессии ДБО

  • проверка статистического профиля плательщика, указанного в реквизитах платежа

  • проверка статистического профиля получателя, указанного в реквизитах платежа.

Статистический профиль формируется системой FraudWall автоматически на основании наблюдаемой истории создания документов в системе ДБО.

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

2. Общие принципы работы системы FraudWall

Система FraudWall устанавливается в локальной вычислительной сети Банка в дополнение к существующей системе ДБО.

Для интеграции системы FraudWall с системой ДБО предусмотрены следующие варианты:

  • система FraudWall получает информацию о платежах клиентов непосредственно из базы данных ДБО либо АБС (работа универсальном режиме)

  • система FraudWall дополнительно анализирует трафик работы клиентов, выступая как WWW-сервер системы ДБО (для системы BS-Client, начиная с версии 3.17.7)

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

Более подробно о взаимодействии с системой ДБО приведено в разделе 11 «Интеграция FraudWall с информационными системами банка».

При анализе трафика клиентов, терминация SSL-соединения клиента банка осуществляется непосредственно на сервере системы FraudWall. В процессе внедрения SSL-сертификат существующего WWW-сервера экспортируется в систему FireWall, тем самым исключая необходимость выполнения каких-либо настроек на стороне клиента банка: клиенты не заметят каких-либо изменений при работе в ДБО.

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

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

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

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

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

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

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

Более подробно об механизме интеграции с системами банка см. 11 «Интеграция FraudWall с информационными системами банка»

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

Среднее время на установку системы FraudWall собственными силами банка «с нуля» составляет несколько часов.

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

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

3. Архитектура системы

3.1. Модули системы

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

Таблица 1. Перечень модулей системы FraudWall:

МодульНазначение
hGuard. Модуль фильтрации HTTP-трафикаОсновное назначение данного модуля - фильтрация всего HTTP-трафика работы клиента в системе ДБО. Дополнительно данный модуль формирует файл дампа трафика клиента, который в дальнейшем будет обработан модулем анализатора трафика.
анализатор трафикаДанный модуль осуществляет анализ файла дампа трафика, сформированного модулем hGuard, на предмет обнаружения подозрительных платежей в системе ДБО.
модуль управленияОсновное назначение данного модуля - управлять остальными модулями FraudWall, осуществлять автоматическое конфигурирование программного обеспечения на сервере и выполнять прочие служебные операции.
удостоверяющий центрРеализует инфраструктуру открытых ключей для всех модулей в системы FraudWall.
интерфейс системыWWW-интерфейс, позволяющий администратору либо пользователю системы FraudWall выполнять необходимые действия в системе.
управляющий www-серверОбеспечивает работу WWW-интерфейса системы FraudWall.
исполнительный www-серверОбеспечивает транспортный уровень между управляющим WWW-сервером, который может быть установлен на выделенном сервере, и модулем управления, установленным на данном сервере.


3.1.1. FraudWall. Интерфейс системы

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

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

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

WWW-интерфейс может работать в 2 режимах:

  • демонстрационный режим

  • работа с реальными данными

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

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

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

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

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

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

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

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

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

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

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

3.1.2. hGuard. Модуль фильтрации HTTP-трафика

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

FraudWall позволяет реализовать два принципиально разных подхода к проверке данных HTTP-трафика:

  • FraudWall устанавливается в разрыв между WWW-сервером банка и клиентом (работа в режиме прокси)

  • формирование содержимого WWW-страниц полностью осуществляется непосредственно на сервере FraudWall

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

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

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

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

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

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

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

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

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

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

3.1.3. Модуль FraudWall. Анализатор трафика

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

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

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

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

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

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

3.1.4. Удостоверяющий центр системы FraudWall

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

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

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

3.1.5. Управляющий WWW-сервер системы FraudWall

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

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

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

3.1.6. Исполнительный WWW-сервер системы FraudWall

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

3.1.7. Модуль управления системы FraudWall

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

3.2. Прочее программное обеспечение

3.2.1. Система мониторинга работоспособности

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

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

3.2.2. Сервер Memcached

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

3.2.3. Сервер баз данных PostgreSQL

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

3.3. Схема взаимодействия компонент системы FraudWall

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

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

Схема взаимодействия компонент системы FraudWall

4. Установка системы FraudWall

4.1. Общее описание

В качестве операционной системы используется предконфигурированная операционная система RedHat Enterprise Linux либо CentOS версии 6.x или 8.x.

Процесс установки максимально автоматизирован и поэтому не требует высокой квалификации.

Процедура установки состоит из следующих шагов:

4.2. Определение архитектуры установки компонент системы FraudWall

Логически система FraudWall разделена на следующие серверы, которые могут быть установлены как на одном физическом компьютере (виртуальной машине), так и разнесены по нескольким компьютерам:

  • Сервер обновлений системы FraudWall (устанавливается по желанию)

  • Сервер управления системы FraudWall

  • Сервер баз данных системы FraudWall (как правило, устанавливается на сервере управления)

  • Сервер анализа трафика (устанавливается по желанию)

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

4.2.1. Подход к тестированию системы FraudWall

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

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

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

4.2.2. Балансировка нагрузки между серверами FraudWall

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

  • регистрация в DNS 2-х и более IP адресов на одно доменное имя

  • использование аппаратного балансировщика

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

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

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

4.3. Требования к аппаратному обеспечению

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

Таблица 3. Рекомендуемая конфигурация серверов

Число клиентовРекомендуемые аппаратные требования для антифрод-системы
до 1000от 1 vCPU, от 1 GB vRAM, 24 GB vDisk (аналог аппаратного RAID 10)
до 5 000от 2 vCPU, от 2 GB vRAM, 64 GB vDisk (аналог аппаратного RAID 10, предпочтительно с кешем обратной записи)
до 10 000от 2 vCPU, от 4GB vRAM, 64GB vDisk (аналог аппаратного RAID 10 с кешем обратной записи)
свыше 10000от 4 vCPU, от 8GB vRAM, 128GB vDisk (аналог аппаратного RAID 10 с кешем обратной записи)

При внедрении решения FraudWall AML дополнительно рекомендуется добавить 2 и более CPU, и по 2 GB на каждые 40 тыс. клиентов

Для целей тестирования возможно использовать и более слабое оборудование.

Оценить загрузку виртуальной машины можно, установив систему и выполнив импорт данных из АБС за последний год работы.

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

4.4. Получение дистрибутивов программного обеспечения

В процессе установки и эксплуатации FraudWall потребуется:

  • лицензионный файл на систему FraudWall

  • CD-диск: kickstart-диск, используемый для быстрой установки операционной системы

    Примечание

    ISO-образ kickstart-диска может быть получен в технической поддержке компании Фродекс по запросу.

    Внимание

    Версия kickstart-диска должна совпадать с версией устанавливаемой операционной системы.

  • DVD-диск: стандартный установочный дистрибутив операционной системы RedHat Enterprise Linux или CentOS

  • Sun Java JRE (при установке модуля BSI системы ДБО BS-Client непосредственно на сервер FraudWall)

  • SSH-клиент (например, PuTTY)

  • файловый менеджер, позволяющий передавать файлы по протоколу SCP (например, плагин WinSCP для файлового менеджера FAR)

4.4.1. Получение дистрибутива RedHat Enterprise Linux

Примечание

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

В качестве операционной системы используется 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, так как он понадобиться в дальнейшем при установке операционной системы.

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

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

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

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

4.4.2. Получение дистрибутива CentOS

Примечание

Если в качестве операционной системы используется RedHat Enterprise Linux, выполнять действия в данном разделе не требуется

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

Примечание

Необходимо загрузить CentOS версии 6.х/8.x . Список зеркал можно найти по следующей ссылке http://wiki.centos.org/Download

Для установки системы 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.

4.4.3. Получение дистрибутива Sun Java JRE

Примечание

Sun Java JRE необходим только в случае установки модуля BSI системы ДБО BS-Client непосредственно на сервер FraudWall.

Для бесплатного скачивания дистрибутива 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

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

Внимание

Если вы используете браузер Opera, то для корректной работы с сайтом www.oracle.com рекомендуется использовать последнюю версию браузера, либо использовать Chrome либо Internet Explorer.

4.5. Установка операционной системы

В качестве операционной системы используется RedHat Enterprise Linux или CentOS версии 6.x (32-битная) или 8.x (64-битная).

Примечание

RedHat Enterprise Linux является промышленной операционной системой, техническая поддержка которой осуществляется компанией RedHat Inc. на платной основе (в рамках так называемой Software Subscription). В рамках Red Hat Enterprise Linux Life Cycle, компания RedHat обязуется выпускать обновления на данную операционную систему и исправлять ошибки, связанные с безопасностью (для версии 6.x обновления будут до 30 ноября 2020 г., для версии 8.x этот срок пока не определен).

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

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

Алгоритм установки операционной системы:

  1. Проверяем, что на межсетевом экране (и при необходимости на proxy-сервере) был предоставлен доступ, необходимый для взаимодействия компонент и получения программного обеспечения системы FraudWall (см. разделы 5.1.7 «Конфигурирование межсетевых экранов» и 10.5 «Механизм получения обновлений» ).

  2. Убеждаемся, что в банке есть NTP-сервер времени, который синхронизирован с глобальными серверами времени посредством Internet.

    Примечание

    Как правило, в качестве NTP-сервера времени используется контроллер ActiveDirectory, на котором поднята соответствующая служба.

    Внимание

    Системы ДБО, системы АБС, а также почтовые сервера банка также должны синхронизироваться с NTP-сервером времени банка

  3. Загружаемся в BIOS и выставляем время на сервере во временной зоне UTC (GMT). На 1 января 2015г. время в зоне UTC отставало от московского на 3 часа (т.е. если московское время 13:00, в BIOS необходимо выставить 10:00).

    Внимание

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

  4. Сверяем версию полученного kickstart-диска и версию установочного дистрибутива Linux. Для версии 8.x kickstart-диск должен называться fraudwall-ks.iso, а для версии 6.x должна совпадать подверсия (например, если вы устанавливаете Red Hat Enterprise Linux версии 6.10, файл установочного дистрибутива будет называться rhel-server-6.10-....iso, а kickstart-диск будет выглядеть как fraudwall-ks-rhel-server-6.10-....iso)

  5. Внимание

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

  6. Внимание

    Обратите внимание, следующие разделы выполняются с учетом версии операционной системы (6.x или 8.x), т.к. порядок установки операционной системы незначительно отличается.

  7. Только для RHEL/CentOS 8.x: Убеждаемся, что на сервере подключено 2 DVD-привода (в первый из которых вставлен DVD-диск операционной системы, а во второй - kickstart-диск).

    Внимание

    Обратите внимание, при установке версии 8.x DVD-диски должны быть вставлены одновременно, причем важна последовательность, в которой сервер будет видеть эти диски.

    В отличие от 6.x, kickstart-диск версии 8.x является незагрузочным диском, поэтому при запуске сервера может возникнуть ошибка вида "Operation system not found".

    В этом случае поменяйте местами DVD-диски (а для виртуальных машин - подключенные iso-файлы) и загрузитесь повторно.

  8. Только для RHEL/CentOS 8.x: В появившемся меню выбираем меню Install RedHat EnterpriseLinux 8.x или Install CentOS 8.x:

    Рисунок 11. Меню начала установки операционной системы RHEL/CentOS 8.x

    Меню начала установки операционной системы RHEL/CentOS 8.x

  9. Только для RHEL/CentOS 8.x: Установка операционной системы выполнится полностью автоматически, каких-либо вопросов больше не должно запрашиваться, процесс установки показывается на черном фоне.

    Внимание

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

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

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

  10. Только для RHEL/CentOS 6.x: Загружаемся с kickstart-диска

    Внимание

    Убедитесь, что вы загружаетесь с kickstart-диска, а не с установочного дистрибутива Linux. Сам kickstart-диск представляет собой CD-диск размером 40 мегабайт, имя ISO-образа должно начинаться как fraudwall-ks-...

  11. Только для RHEL/CentOS 6.x: В появившемся меню выбираем меню Install from CD-ROM:

    Рисунок 12. Меню начала установки операционной системы RHEL/CentOS 6.x

    Меню начала установки операционной системы RHEL/CentOS 6.x

  12. Только для RHEL/CentOS 6.x: При появлении сообщения Disc Not Found, необходимо извлечь kickstart-диск и вставить DVD-диск дистрибутива операционной системы, после чего выбрать пункт Ok:

    Рисунок 13. Сообщение о необходимости установки DVD-ROM диска

    Сообщение о необходимости установки DVD-ROM диска

  13. Только для RHEL/CentOS 6.x: Если система устанавливается на виртуальную машину, то вполне возможно, что при установке будет запрошена необходимость инициализировать виртуальный жесткий диск. В этом случае с помощью кнопок клавиатуры Tab и Enter необходимо выбрать пункт Re-initialize all, как показано на рисунке:

    Рисунок 14. Сообщение о необходимости инициализировать жесткий диск

    Сообщение о необходимости инициализировать жесткий диск


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

    Примечание

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

  15. По завершению процесса установки будет отображено соответствующее уведомление:

    Рисунок 15. Сообщение о завершении установки операционной системы

    Сообщение о завершении установки операционной системы

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

    Внимание

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

  16. После перезагрузки необходимо выполнить первоначальное конфигурирование операционной системы. В RHEL/CentOS 6.x соответствующий интерфейс запустится автоматически, а для RHEL/CentOS 8.x необходимо зайти под пользователем root и паролем 12345, а затем выполнить команду:

    fw_setup

  17. В появившемся окне необходимо указать параметры операционной системы сервера:

    Рисунок 16. Конфигурирование сетевых настроек сервера

    Конфигурирование сетевых настроек сервера

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

    Примечание

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

  19. Если вы на предыдущем этапе ошиблись в указании сетевых настроек, их можно исправить в соответствии с разделом 5.1.6 «Администрирование сетевых настроек».

  20. Только для RHEL/CentOS 6.x: Откроется окно приглашения ввода логина и пароля при работе сервером. Заходим под логином root, пароль 12345

    Рисунок 17. Приглашение на ввод пароля в консоли RedHat Enterprise Linux

    Приглашение на ввод пароля в консоли RedHat Enterprise Linux

  21. При установке на операционную систему RedHat Enterprise Linux необходимо зарегистрировать установленный сервер в соответствии с разделом 12.1 «Процедура регистрации операционной системы RedHat Enterprise Linux».

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

  23. Выполняем команду установки минимально необходимых компонент (для подтверждения установки укажите y и нажмите Enter): yum install fraudwall-system

  24. В командной строке запускаем команду: fw_passwd root

    Меняем пароль учетной записи root на другой.

    Внимание

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

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

  25. Подключаемся к серверу файловым менеджером по протоколу SFTP(SCP) и копируем файл с лицензией в файл /etc/fraudwall/license.dat

    Примечание

    Работа с SFTP (SCP)-клиентом описана в разделе 5.1.3 «Интерфейс передачи файлов посредством протоколов SCP и SFTP»

  26. В SSH-консоли запускаем Midnight Commander командой: mc

  27. Указываем в конфигурационных файлах /etc/fraudwall/fwcontrol.xml и /etc/fraudwall/fraudwall.xml значение всех параметров.

    Примечание

    Содержимое конфигурационных файлов /etc/fraudwall/fwcontrol.xml и /etc/fraudwall/fraudwall.xml, как правило, идентично на всех серверах, где установлена система FraudWall. Если вы устанавливаете операционную систему для еще одного сервера системы FraudWall, можно скопировать эти файлы с ранее настроенного сервера.

    Внимание

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

    Детальное описание параметров приведено в разделах 5.2.3 «Конфигурационный файл fraudwall.xml» и 5.2.2 «Конфигурационный файл fwcontrol.xml».

  28. Если сервер установлен на виртуальную машину VMWare, на установленную операционную систему рекомендуется установить программное обеспечение VMWare Tools. Документацию по установке VMWare Tools на RedHat Enterprise Linux 6 либо CentOS можно получить на сайте компании VMware, Inc.

  29. Устанавливаем обновления на операционную систему в соответствии с разделом 10.3.2 «Установка обновлений на операционную систему в ручном режиме»fw_update -s

  30. Перегружаем сервер командой reboot

4.6. Установка сервера базы данных системы FraudWall

Алгоритм установки сервера баз данных системы FraudWall:

  1. В SSH-консоли выполняем команду установки компонент баз данных: yum install fraudwall-psql

  2. Выполняем команду создания администратора на уровне базы данных: fw_dbadmin

  3. Вводим логин и пароль администратора базы данных (с учетом регистра), указанные в конфигурационном файле fwcontrol.xml.

  4. В SSH-консоли выполняем команду: yum install fraudwall-control

  5. Убеждаемся в корректности данных, указанных в конфигурационных файлах fraudwall.xml и fwcontrol.xml. Для этого выполняем команду: service fw_control restart

    Внимание

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

  6. При необходимости подкорректируйте конфигурационный файл СУБД PostgreSQL /var/lib/pgsql/data/postgresql.conf (например, размер используемой памяти СУБД и т.д.). Описание каждого конфигурационного параметра приведено по тексту этого файла, при необходимости можете проконсультироваться с технической поддержкой.

    Примечание

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

    Если вы изменили конфигурационный файл postgresql.conf, убедитесь в его корректности, для этого выполните команду service postgresql restart

    При выполнении этой команды не должно быть каких-либо ошибок, а процесс сервиса СУБД PostgreSQL должен корректно запустится (в этом можно убедиться в файлах событий в директории /var/log/postgresql)

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

Алгоритм установки сервера управления системы FraudWall:

  1. Проверяем, что ранее был установлен и настроен сервер баз данных (см. раздел 4.6 «Установка сервера базы данных системы FraudWall»).

  2. В SSH-консоли выполняем команду установки компонент управляющего WWW-сервера: yum install fraudwall-master

  3. Открываем WWW-интерфейс системы по ссылке https://IP_адрес_сервера:1000 (на предупреждение браузера о некорректном сертификате нажимаем игнорировать).

    Примечание

    Если у вас не открывается данная ссылка, попробуйте временно полностью отключить использование proxy-сервера в браузере, либо использовать другой браузер (например, Chrome или Firefox).

  4. Входим в систему под логином admin (пароль также admin), являющегося встроенным администратором системы FraudWall. Заходим в пункт "Мои настройки" меню "Пользователи" и меняем пароль.

    Внимание

    Если вы в дальнейшем забыли пароль пользователя admin, его можно сбросить через SSH-консоль. Более подробно см. раздел 5.2.6 «Сброс пароля встроенного администратора системы FraudWall».

  5. В пункте «Администирование» меню «Пользователи» создаем необходимых пользователей (детали см. в разделе 5.2.4 «Администрирование пользователей системы FraudWall»):

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

    Интерфейс администрирования пользователей

    Внимание

    Обязательно удостоверьтесь, что в системе зарегистрирован хотя бы один пользователь с ролью «Администратор», у которого указан e-mail. При отсутствии такого пользователя, почтовые уведомления системного характера отправляться не будут. Детали см. в разделах 8.1.4 «Особенности доставки административных SMTP-сообщений» и 8.1.5 «Особенности доставки SMTP-сообщений при обнаружении подозрительного платежного поручения».

  6. Убеждаемся, что на почтовый ящик администратора приходит тестовое письмо. Для этого в ssh-косоли выполняем команду (скопируйте через буфер обмена):echo test | mail root

    Внимание

    Если письмо не доставлено, посмотрите возможные причины в конце файла /var/log/maillog. При необходимости свяжитесь с технической поддержкой

  7. Заходим в пункт «Профили антифрода» меню «Система» и создаем новый профиль (детали см. в разделе 5.2.8 «Конфигурирование профилей обнаружения мошеннических платежей»):

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

    Интерфейс создания нового профиля

  8. В пункте «Филиалы» привязываем созданный профиль каждому из банков либо его филиалу (детали см. в разделе 5.2.8 «Конфигурирование профилей обнаружения мошеннических платежей»):

    Рисунок 20. Интерфейс параметров банков либо их филиалов

    Интерфейс параметров банков либо их филиалов

    Внимание

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

  9. Все мошеннические платежи, которые были в банке за последние 2 года, необходимо зарегистрировать в системе через меню "Платежи \ Ручной импорт".

    Внимание

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

  10. Импортируйте черные списки, полученные в рамках антидроп-клуба (см. раздел 7.6 «Поддержка межбанковского почтового обмена ("антидроп-клуб")»)

  11. Ознакомьтесь с подходами к интеграции с ДБО и АБС банка (см.11 «Интеграция FraudWall с информационными системами банка»)

  12. Совместно с технической поддержкой выберите оптимальный вариант интеграции (см. 11.2 «Варианты интеграции FraudWall с системами банка»)

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

    Примечание

    Пример SQL-скриптов, которые должны быть выполнены на сервере базы данных ДБО, находятся в директории /usr/share/doc/fraudwall/ в файлах, оканчивающихся на _universal.sql (полное имя файла содержит тип системы ДБО и базы данных системы ДБО).

  14. Если интеграция с ДБО подразумевает создание сайта, работающего через HTTPS, необходимо предварительно экспортировать с существующего WWW-сервера системы ДБО SSL-сертификат в формате PKCS#12, содержащий открытый сертификат, секретный ключ, а также сертификаты всех удостоверяющих центров, выпустивших этот сертификат. Пример процедуры экспорта приведен в разделе 12.2 «Процедура экспорта SSL-сертификата из IIS»

  15. В пункте «Сайты» создаем необходимые сайты, которые будут обслуживаться FraudWall (детали см. в разделе 5.2.10 «Конфигурирование системы FraudWall. Сайты»):

    Рисунок 21. Интерфейс конфигурирования сайтов

    Интерфейс конфигурирования сайтов

  16. На сервере управления в /var/log/fraudwall/siteNNN-afdb.log убеждаемся, что системой FraudWall начали проверяться платежи из анализируемой системы.

4.8. Установка сервера анализа трафика

Установка компонент, осуществляющих фильтрацию и анализ трафика, осуществляется в следующем порядке:

  1. Проверяем, что ранее были установлены и настроены сервер баз данных (см. раздел 4.6 «Установка сервера базы данных системы FraudWall»), а также сервер управления системы FraudWall (см. раздел 4.7 «Установка сервера управления системы FraudWall»).

  2. Выполняем команду установки компонент анализа трафика: yum install fraudwall-site

  3. Выполняем команду синхронизации сертификатов с сервера управления: fw_cert

  4. Выполняем команду получения конфигурации профилей с управляющего WWW-сервера системы FraudWall: fw_control -u profile

  5. Открываем в Midnight Commander файл /var/log/fraudwall/fw_control.log на чтение и проверяем его на наличие ошибок.

    Внимание

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

  6. Выполняем команду получения конфигурации Web-сайтов с управляющего WWW-сервера системы FraudWall: fw_control -u site

  7. Повторно открываем в Midnight Commander файл /var/log/fraudwall/fw_control.log на чтение и проверяем его на наличие ошибок.

    Примечание

    Чтобы быстро проверить файл на наличие ошибок, при его просмотре нажмите кнопку F7 и поищите текст [err], [warn], error или ошибка.

4.8.1. Установка модуля BSI на сервер FraudWall (предварительный этап)

Примечание

Данный раздел нужно выполнять только если сервер анализа трафика будет являться WWW-сервером системы ДБО BS-Client

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

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

  1. Подключаемся к серверу файловым менеджером по протоколу SFTP(SCP) и копируем скаченный ранее установочный дистрибутив с Sun Java JRE (например, jre-7u3-linux-i586.rpm) во временную директорию /tmp

  2. В SSH-консоли запускаем Midnight Commander: mc

  3. Переходим в директорию /tmp

  4. Запускаем команду установки Sun Java JRE (указываем точное имя скаченного rpm-файла дистрибутива Sun Java JRE), например: rpm -i jre-7u3-linux-i586.rpm

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

    Рисунок 22. Ошибки инсталлятора JRE от Oracle, которые можно игнорировать

    Ошибки инсталлятора JRE от Oracle, которые можно игнорировать

  5. Выполняем команду установки компонент системы FraudWall, необходимых для работы модуля BSI ДБО BS-Client: yum install fraudwall-bsi

  6. В Проводнике Windows открываем сетевой диск bsi (либо в файловом менеджере по протоколу SFTP(SCP) переходим в директорию /etc/tomcat6/RT_Ic)

  7. Копируем в нее файл bsi.jar с Web-сервера BS-Client (как правило, он располагается в папке C:\BSSystems\Inetpub\Bsi_scripts\RT_Ic\)

  8. Для работы модуля BSI требуется конфигурационный файл bsi.xml, который должен располагаться в папке /etc/tomcat6/RT_Ic/ на сервере анализа трафика.

    В комплекте FraudWall есть готовый файл bsi.xml.sample, который вы можете скопировать под именем bsi.xml или же создать средствами bsiset.exe (12.3 «Формирование bsi.xml в формате Linux»)

4.8.2. Установка модуля BSI на сервер FraudWall (завершающий этап)

Внимание

Приступать к выполнению действий данного раздела можно только после установки на сервер анализа трафика модуля анализатора трафика, а также модуля фильтрации HTTP-трафика (4.8 «Установка сервера анализа трафика»).

  1. На сервере RTS BS-Client добавляем IP адрес созданного сервера BSI в список соединений (порт аналогично тому BSI, который ранее использовался, как правило, это 12060):

    Рисунок 23. Добавление нового сервера BSI в конфигурацию сервера RTS BS-Client

    Добавление нового сервера BSI в конфигурацию сервера RTS BS-Client

  2. Открываем WWW-интерфейс системы FraudWall и открываем пункт «Конфигурирование» в меню «Система», вкладка «Web-сайты».

  3. Уточняем номер ID сайта, который создан для сайта ДБО BS-Client с модулем BSI, устанавливаемого на сервер FraudWall:

    Рисунок 24. Автоматически сгенерированный ID сайта

    Автоматически сгенерированный ID сайта

  4. В Проводнике Windows открываем сетевой диск siteN (либо в файловом менеджере по протоколу SFTP/SCP переходим в директорию /etc/fraudwall/site/www/siteN), где N-номер ID сайта

  5. Копируем в нее актуальное содержимое Web-сайта системы BS-Client. Как правило, Web-сайт располагается на Web-сервере BS-Client в папке C:\BSSystems\Inetpub\Bsi_sites\rt_ic\

  6. Открываем Internet Explorer и соединяемся с созданным Web-сайтом системы FraudWall. Должен открыться стандартный интерфейс клиента ДБО BS-Client.

    Примечание

    Если сайт не открывается, то смотрим журналы событий модуля BSI (файлы в директории /var/log/tomcat6) и Apache (файлы в директории /var/log/fraudwall) и устраняем зафиксированные ошибки совместно со службой технической поддержки.

4.8.3. Действия при обновлении файлов сайта ДБО BS-Client

Примечание

Действия этого раздела необходимо выполнять только если модуль BSI системы BS-Client установлен непосредственно на сервер анализа трафика

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

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

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

Внимание

При замене файлов сайта не забывайте изменять номер версионного каталога BS-Client, т.к. в браузере клиента некоторые файлы могли закешироваться.

4.9. Установка WWW-сервера обновлений

Внимание

Операционная система WWW-сервера обновлений должна быть установлена согласно разделу 4.5 «Установка операционной системы» , аналогично всем серверам инфраструктуры FraudWall. При этом вносить изменения в конфигурационные файлы fraudwall.xml и fwcontrol.xml не требуется.

Примечание

WWW-сервер обновлений необходимо устанавливать на отдельный компьютер (либо виртуальную машину), на который не будут установлены компоненты FraudWall.

  1. Устанавливаем обновления на программное обеспечение FraudWall командой: fw_update -b

  2. Выполняем команду установки WWW-сервера обновлений: yum install fraudwall-updatesrv

  3. Устанавливаем обновления командой: fw_update -s

    Примечание

    При первом выполнении данной команды на WWW-сервере обновлений из сети Internet будут загружаться обновления Linux, это может занять продолжительное время.

  4. Перегружаем сервер командой reboot

4.10. Инфраструктура FraudNET

4.10.1. Общее описание

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

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

Внимание

Поддержка инфраструктуры FraudNET является опциональной и лицензируется отдельно

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

4.10.2. Синхронизация серверов

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

4.10.3. Настройка серверов для работы в режиме FraudNET

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

  2. В конфигурационном файле /etc/fraudwall/fraudwall.xml дописываем следующие строки:

    <!-- IP адрес главного сервера управления FraudWall -->
    <option name="supermaster_server" value="1.2.3.4"/>
  3. С главного сервера копируем файлы /etc/fraudwall/pki/ca.cer и /etc/fraudwall/pki/ca.key и заменяем ими аналогичные файлы на всех серверах (кроме серверов обновлений) всех филиалов банка.

  4. После замены файлов сертификатов на каждом из серверов выполняем команду fw_cert

  5. На главном сервере управления заходим в интерфейс администрирования по адресу https://IP_адрес_главного_сервера_управления:1000.

  6. Заходим в пункт «Инфраструктура системы» меню «Система» и регистрируем серверы управления филиалов.

    Рисунок 25. Регистрация нового сервера управления

    Регистрация нового сервера управления

4.10.4. Работа с интерфейсом главного сервера управления

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

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

Интерфейс инфраструктуры системы

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

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

Информация о сервере

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

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

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

4.11. Сервис FraudTrack

4.11.1. Общее описание

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

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

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

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

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

Внимание

Поддержка сервиса FraudTrack является опциональной и лицензируется отдельно

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

4.11.2. Схема работы сервиса FraudTrack

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

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

Общая схема работы сервиса FraudTrack

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

4.11.3. Конфигурирование сервиса FraudTrack

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

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

Конфигурирование сервиса FraudTrack

4.11.4. Конфигурирование межсетевого экрана для работы сервиса FraudTrack

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

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

4.11.5. Особенности интеграции с IBM Trusteer Pinpoint Malware Detection

  1. Перед началом конфигурирования FraudTrack необходимо подготовить файл в формате PKCS#7, содержащий секретный ключ, сертификат, а также полную цепочку сертификатов удостоверяющих центров. Секретный ключ и сертификат формируются согласно документации к IBM Trusteer Pinpoint Malware Detection, а затем совместно с набором сертификатов удостоверяющих центров экспортируется в файл формата PKCS#7 (при экспорте в качестве пароля необходимо использовать только цифры и латинские буквы).

    Внимание

    Обратите внимание - сертификат для общения с серверами облачного провайдера - это не сертификат, указываемый при конфигурировании Web-сайта ДБО.

  2. В параметре "URL доступа к API облачного провайдера" необходимо указать URL, сформированный с учетом Application code (см. документацию по IBM Trusteer Pinpoint Malware Detection) по следующему примеру:https://1.2.3.4/88888/api/session

    где 88888 - это присвоенный Application code

  3. Для удобства конфигурирования правил, FraudWall соотносит уровни риска IBM Trusteer Pinpoint Malware Detection по следующему алгоритму:

    Таблица 4. Соответствие уровней риска

    Уровень IBM Trusteer Pinpoint Malware Detection Уровень FraudWall
    0 - 200незначительный
    201 - 400небольшой
    401 - 600средний
    601 - 800большой
    801 - 1000очень большой

4.11.6. Особенности интеграции с Group-IB Bot-Trek Secure Bank

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

  2. Для удобства конфигурирования правил, FraudWall соотносит уровни риска Group-IB Bot-Trek Secure Bank по следующему алгоритму:

    Таблица 5. Соответствие уровней риска

    Уровень Group-IB Bot-Trek Secure Bank Уровень FraudWall
    1 (low)небольшой
    2 (medium)средний
    3 (high)очень большой

4.11.7. Особенности интеграции с Kaspersky Fraud Prevention Cloud

Для взаимодействия с сервером Kaspersky Fraud Prevention Cloud необходимо сформировать PKCS#12 файл (файл формата pfx) содержащий клиентский сертификат, закрытый ключ, а так же цепочку сертификатов сервера KFP Cloud.

Файлы с сертификатами и закрытый ключ предоставляются представителями Kaspersky Lab. Цепочку сертификатов сервера KFP Cloud так же можно экспортировать из браузера в формате PEM (Base64), зайдя на Web страницу сервера KFP Cloud и открыв на просмотр ssl-сертификат сервера.

Сборка осуществляется с помощью утилиты openssl. Для этого Вы можете скопировать все полученные файлы на сервер FraudWall в каталог /tmp и выполнить следующую команду: openssl pkcs12 -export -out kfp.pfx -inkey "закрытый_ключ" -in "клиентский_сертификат" -certfile "цепочка_сертификатов_KFPCloud"

Команда попросит ввести пароль, на котором будет зашифрован полученный файл kfp.pfx. Файл kfp.pfx необходимо забрать с сервера FraudWall и указать в настройках FraudTrack, в Web интерфейсе системы Система->Сайты->FraudTrack в пункте "Файл с сертификатом". В пункте "Пароль доступа к секретному ключу файла" укажите пароль введенный при выполнении команды openssl.

    4.12. Система FraudInform

    4.12.1. Общее описание

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

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

    • антифрод-системы FraudWall, которая обнаруживает подозрительные платежи

    • сервера синтеза и распознавания речи VoiceNavigator

    • голосовой платформы Asterisk, осуществляющей звонок и общение с клиентом, которая устанавливается на сервер управления FraudWall

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

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

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

    4.12.2. Установка системы FraudInform

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

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

    Таблица 6. Список сетевых портов, используемых системой FraudInform

    портынаправление трафика
    UDP 5060 и TCP 5060 (протокол SIP)от сервера управления к АТС Банка
    UDP 10000-20000 (протокол RTP)от АТС Банка и сервера VoiceNavigator к серверу управления
    UDP 10000-32767 (или иной, в зависимости от настроек АТС Банка, протокол RTP)от сервера управления к АТС Банка
    TCP 8000 (протокол RTSP)от сервера управления к серверу VoiceNavigator
    UDP 32768-40960 (протокол RTP)от сервера управления к серверу VoiceNavigator

    Примечание

    В конфигурации FraudInform разрешена работа только по единственному кодеку G711-alaw (также известный как alaw или PCMA). Это необходимо для того, чтобы исключить транскодирование звукового потока (так называемые "бульки" в речи), т.к. VoiceNavigator также поддерживает только этот кодек.

    4.12.3. Установка системы VoiceNavigator

    Установка системы 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. Настройка параметров синтеза

    Настройка параметров синтеза

    Примечание

    В зависимости от лицензии VoiceNavigator также доступны следующие голоса: Александр8000, Анна8000, Владимир8000, Лидия8000, Мария8000, Юлия8000. Вы можете поэкспериментировать с различными голосами, чтобы выбрать наиболее дружелюбный.

    4.12.4. Настройка соединения с VoiceNavigator

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

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

    • server-ip - IP адрес сервера VoiceNavigator

    • rtp-ip - IP адрес сервера управления FraudWall

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

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

    4.12.5. Настройка соединения с ATC Банка

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

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

    • host - IP адрес АТС Банка

    • fromdomain - IP адрес сервера управления FraudWall

    • fromuser - имя/номер_телефона, выделенный для регистрации на АТС

    • defaultuser - имя/номер_телефона, выделенный для регистрации на АТС (аналогично fromuser)

    • remotesecret - пароль для регистрации на АТС

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

    4.12.6. Настройка правил набора номера телефона

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

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

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

    • все 11-ти значные номера, начинающиеся с цифры 7 или 8, перед вызовом приводятся к формату 8хххххххххх

    • для всех 7-ми, 6-ти и 5-ти значных номеров перед вызовом добавляется префикс 8 (т.е. телефонный номер 123-45-67 будет набираться как 81234567)

    • все номера длиной менее 5 цифр считаются внутренними и набираются без изменений

    • звонки на номера других форматов не осуществляются

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

    4.12.7. Настройка специфичных для банка параметров

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

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

    • OPER_NUM - Номер телефона сотрудника банка, по которому будет звонить система, если долго не удается дозвониться до клиента

    • BANK_FROM - Название банка (заключенное в двойных кавычках), которое будет произноситься при приветствии клиента.

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

    4.12.8. Настройка диалога общения с клиентом

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

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

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

    Внимание

    Некорректная конфигурация может привести к полному прекращению работы системы FraudInform.

    4.12.9. Конфигурирование системы FraudInform

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

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

    Вкладка конфигурирования FraudInform

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

    4.12.10. Диагностика работоспособности компонент

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

    • телефон клиента банка, который создал подозрительное платежное поручение, доступен через VIEW fraudwall_contact или VIEW fraudwall_contact_doc

    • в свойствах сайта во вкладке FraudInform выставлено соответствующее значение параметра "Автоматически звонить клиенту по подозрительным платежам"

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

    • на сервере VoiceNavigator запущены оба сервиса STC MRCPServer и STC TTSControl

    • на сервере управления FraudWall правильно сконфигурированы файлы /etc/asterisk/sip_ats.conf и /etc/asterisk/mrcp.conf

    • на межсетевом экране настроен необходимый доступ

    • в АТС банка предпочтительным кодеком выставлен кодек alaw (PCMA, G711-alaw)

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

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

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

    • IP адрес SIP Proxy/Регистратора — IP адрес сервера управления FraudWall

    • Имя пользователя / Имя для авторизации — 100

    • Пароль — fw_password

    • кодек alaw (или PCMA, G711-alaw) должен быть разрешен

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

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

    Внимание

    Иногда бывает так, что сервис STC TTSControl не стартует по причине недостатка памяти (если установлено много голосов генерации, то каждый будет потреблять несколько сотен мб памяти). В данном случае необходимо удалить все голоса кроме одного (например "STC RussianUS Julia 8000"). После удаления голосов необходимо перезагрузить компьютер.

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

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

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

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

    4.12.11. Запись разговоров системы

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

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

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

    5. Администрирование системы FraudWall

    5.1. Администрирование операционной системы

    5.1.1. Общие положения

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

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

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

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

    Компания RedHat предоставляет 3 уровня технической поддержки операционной системы RedHat Enterprise Linux:

    • Self-support Subscription

    • Standard Subscription

    • Premium Subscription

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

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

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

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

    5.1.2. Администрирование через SSH-консоль

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

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

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

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

    5.1.3. Интерфейс передачи файлов посредством протоколов SCP и SFTP

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

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

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

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

    Выбор алгоритма шифрования

    5.1.4. Интерфейс передачи файлов посредством сетевых дисков сети Microsoft

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

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

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

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

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

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

    ЛогинТиповая роль
    rootадминистрирование операционной системы
    dboобновление файлов WWW-сервера ДБО (например, если модуль BSI.JAR установлен непосредственно на сервер FraudWall и он является WWW-сервером для системы ДБО)
    backupавтоматизированный перенос архивов журналов событий и дампов трафика с сервера FraudWall на внешний архивный сервер
    securityдля импорта списков 550-П и просмотра журнала событий из /var/log/fraudwall и /var/log/archive
    podftдля импорта списков 550-П

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

    Внимание

    Обратите внимание, что для установки пароля пользователя в операционной системе необходимо использовать утилиту fw_passwd, поставляемую в комплекте программного обеспечения FraudWall. Сервис SAMBA, который обеспечивает функционал подключения к файловым ресурсам Linux, использует отдельный пароль, не связанный с паролем операционной системы. Поэтому, если в операционной системе пароль пользователя изменен с помощью штатной системной утилиты passwd (а не утилиты fw_passwd), пароль пользователя, используемый для подключения сетевым дискам, не будет синхронизирован.

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

    Таблица 8. Доступные сетевые диски

    ДискДоступАналог файлового пути LinuxНазначение
    disk

    root

    только для чтения

    /позволяет прочитать любой файл на диске сервера
    log

    root, security

    только для чтения

    /var/log/чтение журналов событий, хранящихся в виде файлов
    archive

    root, backup, security

    чтение / запись

    /var/log/archive/для переноса архивных файлов с сервера FraudWall на другой сервер (либо внешний носитель)
    550p

    root, security, podft

    чтение / запись

    /etc/fraudwall/blacklist/550pдля импорта списков по 550-П
    bsi

    root, dbo

    чтение / запись

    /etc/tomcat6/RT_Ic/Для записи на сервер файлов модуля BSI системы BSClient (появляется, если модуль BSI системы BSClient устанавливается непосредственно на сервер FraudWall)
    siteN

    root, dbo

    чтение / запись

    /etc/fraudwall/site/www/siteNДля записи на сервер файлов WWW-сайта с ID=N

    5.1.5. Пользователи операционной системы

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

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

    Внимание

    Для подключения к сетевым дискам сервера необходимо хотя бы один раз установить пароль пользователя root с помощью утилиты fw_passwd.

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

    Внимание

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

    5.1.6. Администрирование сетевых настроек

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

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

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

    Внимание

    При смене IP адреса сервера обязательно проверьте значение IP адресов, указанных в файле /etc/fraudwall/fraudwall.xml (старый IP адрес может встречаться в нескольких местах этого файла)

    5.1.6.1. Действия в случае изменения MAC-адреса сетевой платы сервера

    При изменении MAC-адреса сетевой платы (например, при клонировании виртуальной машины либо замене сетевой платы) необходимо выполнить команду: rm -f /etc/udev/rules.d/70-persistent-net.rulesпосле чего перегрузить сервер командой reboot

    5.1.7. Конфигурирование межсетевых экранов

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

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

    Таблица 9. Доступ, необходимый для любого сервера FraudWall

    доступназначение
    от компьютеров администраторов к этому серверу по TCP 22, 2812, 139, 445 и UDP 137, 138администрирование сервера, доступ к сетевым ресурсам сервера
    от этого сервера к банковскому DNS-серверу по UDP 53 и TCP 53распознавание DNS-имен
    от этого сервера к NTP-серверу синхронизации времени банка по UDP 123синхронизация времени
    от этого сервера к прокси-серверу банка на TCP порт прокси-сервераполучение обновлений из сети Интернет в прокси-режиме (если обновление идет через банковский прокси-сервер). Если в банке устанавливается WWW-сервер обновлений, доступ открывать только для него.
    от этого сервера ко всей сети интернет по TCP 80 и 443получение обновлений из сети Интернет (если обновление идет прямым соединением с сервером в сети Интернет). Если в банке устанавливается WWW-сервер обновлений, доступ открывать только для него.
    от этого сервера к WWW-серверу обновлений по TCP 1003получение обновлений от WWW-сервера обновлений (если он установлен)


    Таблица 10. Дополнительный доступ для сервера управления

    доступназначение
    от пользователей системы FraudWall к этому серверу по TCP 1000работа в WWW-интерфейсе системы
    от этого сервера ко всей сети интернет по TCP 43получение WHOIS-информации об IP адресе в интерфейсе системы (не обязательно)
    от этого сервера к банковскому почтовому серверу по TCP 25отправка информационных сообщений по SMTP-почте
    от банковского почтового сервера к этому серверу по TCP 25получение писем антидроп-клуба


    Таблица 11. Дополнительный доступ для сервера анализа трафика (если установлен)

    доступназначение
    от этого сервера к серверу управления по TCP 1000, 5432 и 11211внутренний информационный обмен
    от сервера управления к этому серверу по TCP 1001внутренний информационный обмен
    от этого сервера к банковскому почтовому серверу по TCP 25отправка информационных сообщений по SMTP-почте


    5.1.8. Подсистема журналирования

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

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

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

    Таблица 12.

    ФайлНазначение
    /var/log/messages Основной файл журналов событий операционной системы
    /var/log/maillog Файл журналов событий почтовой системы
    /var/log/monit Файл журналов событий системы мониторинга и самовосстановления
    /var/log/yum.log Файл журналов событий установки обновлений
    /var/log/sa/sarДД История загрузки ресурсов сервера за заданную дату
    /var/log/postgresql/ postgresql-* Файл журналов событий базы данных PostgreSQL. Имя файла соответствует дате запуска сервиса.
    /var/log/tomcat6/catalina-* Файл журналов событий Tomcat. Имя файла соответствует дате запуска сервиса.
    /var/log/fraudwall/fw_control.log Файл журналов событий модуля управления системы FraudWall.
    /var/log/fraudwall/ fw_master_access.log Файл журналов событий управляющего WWW-сервера системы FraudWall.
    /var/log/fraudwall/ fw_master_error.log Файл журналов ошибок управляющего WWW-сервера системы FraudWall.
    /var/log/fraudwall/ fw_slave_access.log Файл журналов событий исполнительного WWW-сервера системы FraudWall.
    /var/log/fraudwall/ fw_slave_error.log Файл журналов ошибок исполнительного WWW-сервера системы FraudWall.
    /var/log/fraudwall/ hguard.log Файл журналов ошибок модуля «hGuard. Модуль фильтрации HTTP-трафика»
    /var/log/fraudwall/ siteN-af.log Файл журналов ошибок модуля «FraudWall. Анализатор трафика» для сайта с ID=N
    /var/log/fraudwall/ siteN-afdb.log Файл журналов ошибок анализатора платежей из базы данных для сайта с ID=N
    /var/log/fraudwall/ siteN-http_access.log Файл журналов событий WWW-сервера Apache модуля «hGuard. Модуль фильтрации HTTP-трафика» для сайта с ID=N
    /var/log/fraudwall/ siteN-http_error.log Файл журналов ошибок WWW-сервера Apache модуля «hGuard. Модуль фильтрации HTTP-трафика» для сайта с ID=N
    /var/log/fraudwall/ siteN-jk.log Файл журналов событий модуля mod_jk, применимых к сайту с ID=N
    /var/log/fraudwall/ siteN-learn.log Файл журналов событий процесса получения исполненных платежей из базы данных ДБО или АБС
    /var/log/fraudwall/ siteN-learn.dat.last Файл, в котором хранится дата (в зоне UTC), по которую завершилось обучение по исполненным платежам в базе данных ДБО или АБС
    /var/log/fraudwall/ fw_site_access.log Файл журналов событий WWW-сервера Apache модуля «hGuard. Модуль фильтрации HTTP-трафика» для запросов, не относящихся ни к одному из сайтов
    /var/log/fraudwall/ fw_site_error.log Файл журналов ошибок WWW-сервера Apache модуля «hGuard. Модуль фильтрации HTTP-трафика» для запросов, не относящихся ни к одному из сайтов
    /var/log/fraudwall/mod_jk.log Файл журналов событий модуля mod_jk


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

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

    Существуют следующие типы архивных файлов:

    • fwlog - архивы файлов событий системы FraudWall

    • syslog - архивы файлов событий операционной системы

    • dump - архивы дампа трафика работы клиентов

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

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

    5.1.9. Регламентные процедуры

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

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

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

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

    5.2. Администрирование системы FraudWall

    5.2.1. Общие положения

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

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

    5.2.2. Конфигурационный файл fwcontrol.xml

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

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

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

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

    Внимание

    Так как файл fwcontrol.xml имеет синтаксис XML, при указании значений параметров необходимо учитывать необходимость преобразования некоторых спецсимволов. Детали можно уточнить по ссылке http://ru.wikipedia.org/wiki/XML

    Таблица 13. Перечень параметров файла fwcontrol.xml

    параметрдопустимые значенияназначение
    database_masteruserтекст

    логин администратора базы данных

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

    Внимание

    Логин должен содержать латинские символы только нижнего регистра, цифры и символ "_".

    Значение логина и пароля не должно быть равно зарезервированным командам PostgreSQL. Например, в качестве логина нельзя использовать “user”, “superuser” и т.д. - при таких значениях в логах PostgreSQL (в директории /var/log/postgresql/) будет зафиксирована ошибка.

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

    database_masterpasswordтекстпароль администратора базы данных
    archive_passwordтекст

    пароль шифрования архивов журналов событий

    Если значение параметра archive_password пустое, шифрование архивов не осуществляется.

    Примечание

    Шифрование архивов журналов событий возможно только в случае, если в качестве архиватора используется rar. В остальных случаях значение этого параметра игнорируется.


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

    Внимание

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

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

    Примечание

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

    5.2.3. Конфигурационный файл fraudwall.xml

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

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

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

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

    Внимание

    Так как файл fraudwall.xml имеет синтаксис XML, при указании значений параметров необходимо учитывать необходимость преобразования некоторых спецсимволов. Детали можно уточнить по ссылке http://ru.wikipedia.org/wiki/XML

    Таблица 14. Перечень параметров файла fraudwall.xml

    параметрдопустимые значенияназначение
    log_levelчисло от 0 до 9уровень логирования компонент FraudWall, устанавливаемый по-умолчанию
    tz_moscowdeltaцелое число от -23 до +23смещение времени этого сервера относительно московского времени в часах
    ad_serverIP адресIP адрес контроллера ActiveDirectory
    master_serverIP адресIP адрес сервера, на котором установлен управляющий WWW-сервер FraudWall
    dbha_serverIP адресуказывает IP адрес резервного сервера базы данных. Если такого сервера не установлено, указывается пустое значение
    database_serverIP адресIP адрес сервера, на котором установлены компоненты базы данных системы FraudWall
    database_userтекст

    логин пользователя базы данных

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

    Внимание

    Логин должен содержать латинские символы только нижнего регистра, цифры и символ "_".

    Значение логина и пароля не должно быть равно зарезервированным командам PostgreSQL. Например, в качестве логина нельзя использовать “user”, “superuser” и т.д. - при таких значениях в логах PostgreSQL (в директории /var/log/postgresql/) будет зафиксирована ошибка.

    Примечание

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

    Учетная запись пользователя баз данных (параметр database_user в файле fraudwall.xml) используется для штатной работы всех модулей системы FraudWall. На уровне базы данных ей предоставлены ограниченные права доступа.

    Учетная запись администратора баз данных (параметр database_masteruser в файле fwcontrol.xml) используется только модулем управления для автоматического создания схемы базы данных. На уровне базы данных ей предоставлены неограниченные права доступа.

    database_passwordтекстпароль пользователя базы данных
    www_password_daysчислоуказывает, через сколько дней требовать у пользователя FraudWall сменить пароль. Отсутствие параметра или значение, равное 0, означает бесконечный срок жизни пароля пользователя в интерфейсе FraudWall
    memcached_serverIP адресIP адрес сервера, на котором установлен сервер Memcached (необходимо указать IP адрес управляющего WWW-сервера системы FraudWall)
    mail_serverIP адрес

    IP адрес банковского почтового сервера

    При изменении этого параметра необходимо выполнить команду: fw_control -s mail

    Внимание

    ВНИМАНИЕ! Почтовые сообщения, формируемые системой, носят важный характер. Обязательно проверьте конфигурацию вашего почтового сервера, что эти сообщения не будут блокироваться антиспам- и прочими фильтрами.

    mail_sasl_userтекстЛогин для SASL-аутентификации на почтовом сервере. Если SASL-аутентификация не требуется, укажите пустое значение.
    mail_sasl_passwordтекстПароль для SASL-аутентификации на почтовом сервере. Если SASL-аутентификация не требуется, укажите пустое значение.
    mail_frome-mail адресПочтовый адрес, от имени которого будут отправляться все почтовые сообщения с сервера FraudWall
    autoupdate_fwon/offon - автоматически устанавливать обновления компонент системы FraudWall, off - только информировать по почте
    autoupdate_dbon/offon - автоматически устанавливать обновления справочников (справочник БИК, GeoIP и т.д., off - только информировать по почте
    autoupdate_rhon/offon - если включено автообновление компонент FraudWall, то дополнительно обновлять операционную систему

    5.2.3.1. Действия при редактировании файла fraudwall.xml

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

    Примечание

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

    5.2.4. Администрирование пользователей системы FraudWall

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

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

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

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

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

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

    Сброс пароля пользователя

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

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

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

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

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

    Роли пользователей системы FraudWall

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

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

    5.2.5. Интеграция с ActiveDirectory

    Аутентификация пользователей 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 не требуется.

    Примечание

    Если в /etc/fraudwall/fraudwall.xml нет опции ad_server, необходимо вручную добавить ее в конце файла перед строчкой </config>, как показано ниже:

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

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

    service fw_master restart

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

    5.2.6. Сброс пароля встроенного администратора системы FraudWall

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

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

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

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

    5.2.7. Аудит пользователей системы FraudWall

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

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

    Интерфейс аудита системы FraudWall

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

    5.2.8. Конфигурирование профилей обнаружения мошеннических платежей

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    5.2.9. Конфигурирование системы FraudWall. Банки и филиалы

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

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

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

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

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

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

    Внимание

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

    5.2.10. Конфигурирование системы FraudWall. Сайты

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

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

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

    Внимание

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

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

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

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

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

    При конфигурировании нескольких Web-сайтов, работающих по протоколу HTTP, необходимо учитывать следующие правила:

    • На одной паре «IP адрес сервера FraudWall:TCP порт сайта» может быть несколько Web-сайтов.

    • Для определения Web-сайта из зарегистрированных в системе FraudWall используется соответствие «доменное имя сайта:TCP порт сайта».

    • Имя сайта, указанное клиентом в Internet-браузере (dbo.bank.ru в строке http://dbo.bank.ru:8080) должно совпадать с основным либо дополнительным доменным именем в сети Internet, указанных в свойствах Web-сайта в конфигурации FraudWall. Регистр символов не учитывается

    • Для URL вида http://1.2.3.4, в качестве доменного имени Web-сайта FraudWall необходимо указать 1.2.3.4

    • TCP-порт, указанный клиентом в Internet-браузере (80 в строке http://dbo.bank.ru или 8080 в строке http://dbo.bank.ru:8080), должен совпадать с TCP-портом, указанном в свойствах Web-сайта в конфигурации FraudWall

    При конфигурировании нескольких Web-сайтов, работающих по шифрованному протоколу HTTPS, необходимо учитывать следующие правила:

    • На одной паре «IP адрес сервера FraudWall:TCP порт сайта» может быть только один Web-сайт.

    • Имя сервера, указанного клиентом в URL, игнорируется. Оно может как совпадать с именем, указанным в параметре «Доменное имя в сети Интернет», так и отличаться от него.

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

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

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

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

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

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

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

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

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

    5.2.11. Кеширование трафика на стороне FraudWall

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

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

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

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

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

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

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

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

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

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

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

    Внимание

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

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

    5.2.12. Балансировка нагрузки между WWW-серверами ДБО

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

    Внимание

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

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

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

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

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

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

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

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

    Список внутренних 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 и WWW-серверов ДБО

    5.2.13. Высвобождение лицензии в случае закрытия клиентом расчетного счета в банке

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

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

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

    • Вариант 1: автоматическое освобождение лицензии

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

    • Вариант 2: освобождение лицензии в ручном режиме через интерфейс "Аналитика по плательщику"

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

      Для этого необходимо зайти в интерфейс "Аналитика по плательщику", получить аналитику по ИНН клиента, закрывшего счет, а затем в группе "Очищение статистики по плательщику" указать дату закрытия счета (т.е. дату, до которой будет очищена статистика) и причину очищения статистики:

      Рисунок 55. Очищение статистики по плательщику

      Очищение статистики по плательщику

      После очищения статистики рекомендуется получить аналитику по очищаемому ИНН клиента повторно - в отчете "Накопленная статистика по плательщику" должен быть текст следующего содержания:

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

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

      Примечание

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

    • Вариант 3: высвобождение лицензий на основе актуального списка ИНН клиентов банка

      Если вручную очищать лицензии не удобно, предусмотрено очищение лицензий на основе файла со списком ИНН клиентов банка.

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

      01234567890
      23456780924
      12345
      1234678901234

      Внимание

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

      Примечание

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

      Созданный файл запишите на сервер управления в директорию /tmp, а затем выполните команду (вместо filename укажите полный путь к файлу):

      fw_control -c corplist -i filename

    5.2.14. Решение проблем с базой данных

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

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

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

    • из-за аппаратных проблем может возникнуть ситуация, когда в log-файлах FraudWall фиксируются ошибки следующего рода:

      ОШИБКА: Database error detected: 'ERROR: Invalid page header in block 75 of relation base/16385/16438'

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

    Внимание

    В процессе сжатия базы данных все сервисы FraudWall будут остановлены

    5.2.15. Очищение базы данных FraudWall

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

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

    5.3. Архивирование и восстановление из архива

    5.3.1. Общие положения

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

    • создание snapshot-образов виртуальных машин (наиболее предпочтительный вариант)

    • создание посекторной копии жесткого диска серверов FraudWall (требует специализированного программного обеспечения)

    • создание архива конфигурации сервера штатными утилитами FraudWall fw_backup и fw_restore

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

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

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

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

    5.3.2. Создание архивной копии с помощью утилиты fw_backup в интерактивном режиме

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

    5.3.3. Создание архивной копии с помощью утилиты fw_backup как cron-задание

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

    Для выполнения утилиты 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*

    Внимание

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

    5.3.4. Восстановление из архивной копии с помощью утилиты fw_restore

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

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

    1. Если предполагается восстанавливать архив на другом физическом сервере, необходимо предварительно на нем установить "чистую" операционную систему (т.е. выполнить действия в разделе 4.5 «Установка операционной системы» до начала копирования файла с лицензией, т.к. дальнейшие пункты (в т.ч. редактировать файлы /etc/fraudwall/fwcontrol.xml и /etc/fraudwall/fraudwall.xml) выполнять не обязательно).

    2. Перед началом восстановления скопируйте файл архивной копии в директорию/var/tmp (убедитесь, что в ней нет других архивных файлов fwbackup-*.tgz)

      Примечание

      Работа с SFTP (SCP)-клиентом описана в разделе 5.1.3 «Интерфейс передачи файлов посредством протоколов SCP и SFTP»

    3. Для начала восстановления из архивной копии запустите команду fw_restore

    4. После восстановления проверьте и при необходимости подкорректируйте IP адреса, указанные в файле /etc/fraudwall/fraudwall.xml

    5. Перегрузите сервер командой reboot

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

    7. Установите обновления на операционную систему в соответствии с разделом 10.3.2 «Установка обновлений на операционную систему в ручном режиме»fw_update -s

    8. Убедитесь в работоспособности восстановленного сервера

    5.3.5. Восстановление из snapshot-образов и посекторной копии жесткого диска

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

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

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

    5.3.6. Миграция сервера FraudWall на другой физический сервер.

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

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

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

    Внимание

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

    5.3.6.1. Подготовительные мероприятия

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

    Примечание

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

    На новый сервер нужно установить "чистую" операционную систему (т.е. выполнить действия в разделе 4.5 «Установка операционной системы» до начала копирования файла с лицензией, т.к. дальнейшие пункты (в т.ч. редактировать файлы /etc/fraudwall/fwcontrol.xml и /etc/fraudwall/fraudwall.xml) выполнять не нужно).

    Внимание

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

    Примечание

    Если взаимодействие с Интернет осуществляется через proxy-сервер, то необходимо произвести настройку согласно пункту 10.5.2 «Конфигурирование получения обновлений в проксированном режиме»

    5.3.6.2. Миграция сервера: создание резервной копии старого сервера

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

    Переносим /var/tmp/fwbackup-ГГГГММДД_ЧЧММСС-<имясервера>.tgz с старого сервера на новый.

    5.3.6.3. Миграция сервера: восстановление резервной копии на новом сервере
    1. Выключаем старый сервер.

    2. Выполняем команду на новом сервере service fw_setup start

    3. Изменяем доменное имя и IP адрес на значения старого сервера.

    4. Перезагружаем новый сервер командой reboot

    5. На новом сервере (он будет доступен уже по IP адресу старого сервера) восстанавливаем конфигурацию сервера командой fw_restore

    6. Повторно перегружаем сервер командой reboot

    7. Выполняем обновление системных пакетов командой fw_update -s

    5.3.6.4. Миграция сервера: проверка работоспособности

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

    1. Проверяем доступность WEB-интерфейса системы FraudWall.

    2. Обновляем статус всех серверов в WEB-интерфейсе FraudWall во вкладке инфраструктура. Не должно быть ошибок, а время последнего обновления статуса серверов должно быть актуальным.

      Рисунок 57. Просмотр состояния сервера FraudWall

      Просмотр состояния сервера FraudWall


    3. Просматриваем логи /var/log/fraudwall/fw_control.log на наличие ошибок (строки содержащие "[err]").

    4. При миграции сервера управления необходимо проверить, что все сайты подключаются к соответствующим БД (АБС или ДБО). Для этого необходимо проверить, что последние записи в файлах /var/log/fraudwall/siteNNN-afdb.log не содержат ошибок (строки содержащие "[err]").

    5. При миграции сервера анализа трафика проверяем работоспособность связки нового сервера анализа трафика с сервером управления. Для этого необходимо проверить, что файл /var/log/fraudwall/siteNNN-af.log на сервере анализа трафика не содержат ошибок (строки содержащие "[err]").

      Дополнительно проверяем работоспособность тонкого клиента BS-Client.

    5.4. Создание отказоустойчивой конфигурации

    5.4.1. Общие положения

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

    Примечание

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

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

    • WWW-сервер обновлений FraudWall

    • основной сервер FraudWall

    • резервный сервер FraudWall

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

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

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

    5.4.2. Создание резервного сервера

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

    1. Выделить IP адрес для резервного сервера.

      Примечание

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

    2. Установить операционную систему согласно раздела 4.5 «Установка операционной системы»

      Примечание

      Конфигурационные файлы fraudwall.xml и fwcontrol.xml в процессе установки лучше скопировать с основного сервера управления

    3. Установить сервер баз данных в соответствии с разделом 4.6 «Установка сервера базы данных системы FraudWall»

    4. На основном сервере запустить команду fw_dbha

      Внимание

      Обратите внимание, конфигурирование горячего резервирования осуществляется только на основном сервере

    5. Примерно через 10 минут в интерфейсе "Инфраструктура серверов" меню "Система" появится резервный сервер. Для удобства рекомендуется переименовать его как "резервный сервер".

    5.4.3. Порядок действий в случае сбоя основного сервера

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

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

    1. Убедится, что отказавший основной сервер полностью выключен

    2. Зайти в консоль операционной системы резервного сервера и выполнить команду fw_dbha

    3. В появившемся диалоге выбрать режим "основной сервер не работает, восстановить этот сервер как основной"

    4. Перегрузить сервер командой reboot

    5. Зайти в Web-интерфейс системы и убедится в работоспособности сервера

      Примечание

      При восстановлении сетевых параметров, на резервном сервере не меняется доменное имя. При необходимости его можно поменять в соответствии с разделом 5.1.6 «Администрирование сетевых настроек»

    5.4.4. Порядок действий при восстановлении отказавшего сервера

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

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

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

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

    2. На быстром сервере (он сейчас резервный) необходимо выполнить команду fw_dbha

      и выбрать режим "основной сервер не работает, восстановить этот сервер как основной"

    3. На медленном сервере установить IP адрес резервного сервера командой service fw_setup start (если будут ошибки конфликта IP адресов, их можно игнорировать)

    4. Перегрузить оба сервера командой reboot

    5. На быстром сервере выполнить команду fw_dbha и указать IP адрес резервного сервера (он сейчас установлен на медленном сервере)

    6. Убедится, что Web-интерфейс FraudWall доступен (как и прежде, он находится по IP адресу основного сервера, но сейчас его обрабатывает быстрый сервер)

    5.4.5. Переконфигурирование резервного сервера

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

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

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

    2. На резервном сервере, который должен быть переконфигурирован как обычный сервер, выполнить команду fw_dbha и выбрать режим "вывести этот сервер из резервирования"

    3. После завершения настроек перегрузить сервер командой reboot

    6. Обнаружение мошеннических платежей

    6.1. Общие принципы обнаружения мошеннических платежей

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

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

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

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

    • получатель - физическое лицо

    • получатель - юридическое лицо

    • получатель - платежный шлюз

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

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

    Помимо статистики «плательщик - получатель», получаемой из реквизитов платежного поручения, система FraudWall также накапливает статистику по компьютеру клиента (с каких IP адресов работает клиент в ДБО и т.д.).

    Статистика автоматически формируется с учетом особенностей платежей каждого клиента.

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

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

    Рисунок 58. Последовательность анализа документа системой FraudWall

    Последовательность анализа документа системой FraudWall

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

    Выставляемые флаги могут быть как логическими (т.е. принимать значения ПРАВДА, ЛОЖЬ НЕИЗВЕСТНО), уровневыми (т.е. НЕЗНАЧИТЕЛЬНЫЙ, НЕБОЛЬШОЙ, СРЕДНИЙ, БОЛЬШОЙ, ОЧЕНЬ БОЛЬШОЙ, НЕЕСТЕСТВЕННЫЙ, НЕИЗВЕСТНО), либо числовыми (обычное число с запятой).

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

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

    1. встроенные правила (поставляемые разработчиком системы)

    2. правила, создаваемые вручную через Web-интерфейс

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

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

    6.2. Конфигурирование правил и критериев обнаружения мошеннических платежей

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

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

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

    Правом создания либо редактирования профиля наделены только пользователи с ролью «администратор» либо «сотрудник службы безопасности».

    Внимание

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

    Описание каждого из параметров профиля приведено в online-помощи Web-интерфейса системы.

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

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

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

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

    Использование встроенных правил

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

    Таблица 15.

    Уровень правилаОбласть применения
    проверка по 167-ФЗПравила обнаружения мошеннических платежей, использующие только признаки переводов денежных средств без согласия клиента, устанавливаемые 167-ФЗ
    похоже на кражу средствОчень высокое подозрение на мошеннический платеж: с компьютера недавно был мошеннический платеж и т.д.
    основные критерии обнаруженияИспользуются правила, реализующие основные критерии обнаружения мошеннических платежей
    рекомендуемый набор правилТиповой набор правил, рекомендуемый к эксплуатации
    экспериментальные правилаАктивируются правила, предназначенные для тестирования и экспериментальных исследований


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

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

    Примечание

    Образно наборы правил можно представить в виде обычной мишени с "кольцами". Чем ниже уровень - тем ближе кольцо к центру, а соответственно, точнее попадание в цель (т.е. обнаружение мошеннического платежа).

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

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

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

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

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

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

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

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

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

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

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

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

    6.2.3. Особенности конфигурирования правил при неизвестных значениях флагов

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

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

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

    6.3. Тестирование обнаружения мошеннических платежей

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

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

    Самый простой способ проверки - это поместить какого-либо несуществующего получателя в черный список. Для этого необходимо зайти в интерфейс получения аналитического отчета по получателю - юридическому лицу (интерфейс «Получатель» меню «Аналитика»), сделать выборку по ИНН 1234567890 и в группе «Статус» установить соответствующий статус:

    Рисунок 60. Помещение получателя в черный список

    Помещение получателя в черный список

    После выставления статуса, необходимо зайти под клиентом в ДБО и создать рублевый платеж на получателя с этим ИНН.

    Внимание

    При создании тестового платежа необходимо, чтобы платеж соответствовал всем требованиям платежных документов в РФ - номер расчетного счета должен относится к юридическому лицу, код валюты 810 и т.д. Например, расчетный счет должен выглядеть как 40702810…

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

    Необходимо кликнуть мышкой на этот документ и проверить идентичность всех полей документа с тем, что было введено в интерфейсе ДБО.

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

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

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

    6.4. Тонкая настройка обнаружения мошеннических платежей

    6.4.1. Снижение уровня ложного срабатывания системы

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

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

    • определить список правил, которые наиболее часто формируют ложное срабатывание

    • определить массовость проблемы - т.е. относится ли ложное срабатывание ко всем клиентам, либо ярко выражена только среди определенных клиентов

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

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

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

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

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

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

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

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

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

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

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

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

    Для повышения вероятности обнаружения мошеннических платежей рекомендуется:

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

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

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

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

    • Если клиенту не требуется платить в пользу платежных шлюзов, рекомендуется установить небольшое значение (100 - 200 рублей) в поле «сверхбольшая сумма платежей в пользу платежных шлюзов».

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

    6.4.3. Использование утилиты fw_forecast

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

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

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

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

    Внимание

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

    6.5. Анализ дампов трафика клиентов в ручном режиме

    Детальный анализ действий злоумышленника в системе ДБО можно осуществить на основе анализа архивных файлов дампа трафика (см. также раздел 5.1.8 «Подсистема журналирования»).

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

    В целях экономии места на архивном носителе, после переименования файл дампа сжимается архиватором rar (если установлен) либо tar (со сжатием bzip2), которые перед анализом необходимо распаковать во временную директорию.

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

    Извлеченные файлы дампа трафика создаются с учетом времени аутентификации (как успешной, так и не успешной) по маске: ЛогинПользователяКлиента[_ЛогинЮрЛица ]-ГГГГММДД_ЧЧММСС_UTC.dat

    Примечание

    Значение поля «ЛогинЮрЛица» указывается только в том случае, если в ДБО предусмотрен не только логин пользователя клиента, но и логин юридического лица (например, в этом случае для разных логинов юр.лиц CORP1 и CORP2 могут быть созданы пользователи с одинаковыми логинами director).

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

    6.5.1. Подготовка файлов для обработки

    Примечание

    Файлы дампа, как правило, занимают на диске много места. Поэтому работу с ними лучше осуществлять в директории /var/tmp.

    Предварительно убедитесь, что на соответствующем разделе достаточно места командой: df /var -H

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

    • дамп за текущий день находится в директории /var/log/fraudwall

    • дамп за предыдущие периоды помещаются в архивные файлы (один файл архива содержит дампы всех сайтов за одни сутки) в директорию /var/log/archive.

      Внимание

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

      Примечание

      Согласно разделу 5.1.9 «Регламентные процедуры», файлы из директории /var/log/archive должны переносится на внешний носитель (сетевой диск, DVD-диск и т.д.)

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

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

    Пример 1.

    tar -x -j -f srv1-dump-20120903_180001.tar.bz2 -C /var/tmp/dump/srv1

    tar -x -j -f srv2-dump-20120903_180001.tar.bz2 -C /var/tmp/dump/srv2


    Внимание

    В кластерной установке распакованные файлы дампов разных серверов называются одинаково (например, site1-dump.dat). Поэтому при распаковке архивов разных серверов необходимо указывать разные поддиректории (например, /var/tmp/dump/srv1 и /var/tmp/dump/srv2).

    6.5.2. Фильтрация сессий для извлечения из архива

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

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

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

    Таблица 16. Критерии фильтрации сессий клиентов

    Критерий фильтрацииОпция
    логин пользователя клиента-u ЛогинПользователяКлиента
    логин юр. лица-g ЛогинЮрЛица
    IP адрес компьютера клиента-i IP_адрес
    CID (внутренний ID компьютера клиента)-c CID_компьютера

    Внимание

    Обратите внимание, что для некоторых систем ДБО логин пользователя и юр.лица могут быть регистрозависимы (например, это ДБО BSClient), поэтому их необходимо указывать в соответствующем регистре.

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

    6.5.3. Запуск утилиты формирования файлов дампов сессий клиентов

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

    Таблица 17. Утилиты анализа файлов дампов

    Система ДБОНаименование утилиты
    BS-Clientfw_bsclient
    iSimpleBank 2.0fw_isimple
    Finacle eBankingfw_finacle

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

    Таблица 18. Обязательные опции запуска утилиты анализа файлов дампов

    ОпцияНазначение
    -wПризнак того, что необходимо записать файл дампа в соответствии с критериями
    -s ДиректорияАнализаДиректория, в которой находятся распакованные файлы (внутри нее могут находится поддиректории, например, от разных серверов системы FraudWall)
    -d ДиректорияРезультатаДиректория, в которую будут записаны результирующие файлы
    -l ЛогФайл(опционально) файл журнала событий обработки файлов дампа. Если опция не указывается, журнал событий будет выведен на экран


    Внимание

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

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

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

    Пример 2. Создание файла с сессиями клиента с логином user01

    fw_bsclient -w -s /var/tmp/a -d /var/tmp/result -l result.log -u user01


    Пример 3. Создание файла с сессиями клиентов с логинами user01 или user02

    fw_bsclient -w -s /var/tmp/a -d /var/tmp/result -l result.log -u user01 -u user02


    Пример 4. Создание файла с сессиями клиента с логином user01 или с IP адреса 198.3.45.89

    fw_bsclient -w -s /var/tmp/a -d /var/tmp/result -l result.log -u user01 -i 198.3.45.89


    Пример 5. Создание файла с сессиями всех клиентов, которые были с IP адреса 198.3.45.89

    fw_bsclient -w -s /var/tmp/a -d /var/tmp/result -l result.log -i 198.3.45.89


    Внимание

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

    7. Обучение системы

    7.1. Самообучение системы

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

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

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

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

    Рисунок 64. Конфигурирование параметра срока первоначального накопления статистики

    Конфигурирование параметра срока первоначального накопления статистики

    Статистическая модель автоматически корректируется в процессе эксплуатации системы.

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

    Такое обучение возможно в двух режимах:

    Внимание

    Следует обратить внимание, что FraudWall считает все платежи, находящиеся в базе данных ДБО, созданными клиентом (т.е. не мошенническими). Поэтому необходимо обязательно дополнительно ввести все мошеннические платежи, зафиксированные в банке, через WWW-интерфейс системы FraudWall (см. раздел 7.5 «Ручной ввод данных о мошенническом платеже»).

    7.2. Обучение через ODBC-подключение к базе данных ДБО

    Процесс обучения через ODBC-подключение запускается автоматически, как только в конфигурации сайта в группе параметров "Анализируемая база данных" заполнены необходимые поля:

    • идентификатор DSN, а также логин и пароль для подключения к базе данных ДБО через ODBC

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

    Рисунок 65. Конфигурирование параметров обучения через ODBC-подключение

    Конфигурирование параметров обучения через ODBC-подключение

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

    Внимание

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

    7.3. Обучение на основании файла экспорта

    Внимание

    Начиная с версии 2.3.0, обучение на основании файла экспорта заменено более совершенным механизмом (см. раздел 7.2 «Обучение через ODBC-подключение к базе данных ДБО»).

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

    Рекомендуемая процедура первоначального обучения системы следующая:

    • Выгрузка из АБС в файл определенного формата всех платежей (включая мошеннические) всех клиентов за продолжительный период времени

    • Запуск утилиты обучения статистических профилей клиентов на основании выгруженных данных

    • Ручной ввод реквизитов всех мошеннических платежей через WWW-интерфейс системы FraudWall

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

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

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

    7.3.1. Формат файла для обучения из внешних источников

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

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

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

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

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

    7.3.2. Использование утилиты обучения статистических профилей клиентов

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

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

    • на сервер во временную папку (например, в /var/tmp/) записывается файл с выгруженными данными

      Внимание

      В целях безопасности утилита обучения автоматически сбрасывает свои привилегии до уровня пользвателя fwsite. Если в дальнейшем не создадутся .log и .last файлы, используйте директорию /var/tmp/ или /tmp/, для которой необходимые права даны по-умолчанию.

    • запускается одновременно две SSH-консоли на сервер под учетной записью root

    • в одной из SSH-консолей запускается следующая команда: fw_import -d имя_файла

    • во второй SSH-консоли запускается Midnight Commander (команда mc), и открывается на чтение файл имя_файла.log (т.е. файл, имя которого состоит из имени файла с выгруженными данными с добавлением .log в конце).

    • периодически осуществляется проверка ошибок импорта, которые фиксируются в .log файле - для этого можно закрыть и открыть .log файл в Midnight Commander повторно. Можно также запустить следующую команду, которая будет выводить последние строки .log-файла на экран: tail -f имя_файла.log

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

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

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

    Примечание

    После успешного завершения процесса обучения не забудьте удалить .csv, .log, а также .last файлы - они больше не нужны

    7.4. Ведение черных и белых списков получателей

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

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

    Примечание

    В рамках технической поддержки системы FraudWall черные и белые списки получателей не распространяются. Вы можете их вести вручную (см. 7.4.1 «Ведение черных и белых списков получателей в ручном режиме»), либо использовать уже существующие черные списки получателей (см. 7.6 «Поддержка межбанковского почтового обмена ("антидроп-клуб")» и 7.7 «Интеграция с системой FraudMonitor»).

    7.4.1. Ведение черных и белых списков получателей в ручном режиме

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

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

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

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

    7.5. Ручной ввод данных о мошенническом платеже

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

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

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

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

    • формирование аналитических отчетов по мошенничеству в банке

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

    Рисунок 67. Интерфейс ввода данных о мошенническом платеже

    Интерфейс ввода данных о мошенническом платеже

    Внимание

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

    7.6. Поддержка межбанковского почтового обмена ("антидроп-клуб")

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

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

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

    7.6.1. Автоматическая обработка входящих почтовых сообщений

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

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

    Внимание

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

    Если на сервере управления в файле /var/log/maillog нет соответствующих событий по приему почтового сообщения, необходимо убедиться, что внутрибанковский почтовый сервер отправлял письма на IP адрес сервера управления, и что на межсетевых экранах, которые находятся между ними, открыт соответствующий доступ (т.е. с внутрибанковского сервера на сервер управления по порту TCP 25)

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

    7.6.2. Ручная загрузка Excel-файла через WWW-интерфейс FraudWall

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

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

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

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

    7.6.3. Формирование Excel-файла, используемого при обмене в рамках "антидроп-клуба"

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

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

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

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

    Примечание

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

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

    7.7. Интеграция с системой FraudMonitor

    Начиная с версии 5.6.1, поддержка интеграции системы FraudWall с системой контроля мошенничества FraudMonitor (разработчиком которой является компания Group-IB, http://www.group-ib.ru/), полностью прекращена.

    Внимание

    Не путайте решение FraudMonitor с решением SecureBank Bot-Trek, которое также разработано компанией Group-IB, а также с решением FraudTrack, которое разработано компанией Фродекс.

    Примечание

    Система FraudMonitor предназначалась для централизованного сбора информации об инцидентах в банках. В настоящий момент данной задачей занимается ФинЦЕРТ ЦБ РФ, поэтому необходимости в системе FraudMonitor нет.

    7.8. Импорт списков по 550-П (639-П)

    В системе FraudWall реализована функция автоматического импорта списков, получаемых банком в рамках 550-П (639-П).

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

    Для импорта файлов на сервере управления предусмотрен сетевой диск сети Microsoft с именем "550p". Для подключения к нему необходимо запустить Проводник, ввести в пути текст вида \\1.2.3.4\550p (вместо 1.2.3.4 нужно указать IP адрес или доменное имя сервера управления FraudWall). В качестве логина необходимо указать одного из пользователей операционной системы: root, secure или podft с соответствующим паролем (более детально см. 5.1.4 «Интерфейс передачи файлов посредством сетевых дисков сети Microsoft»).

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

    Внимание

    С этого ресурса можно удалять только некорректные XML-файлы. Все ранее обработанные XML-файлы удалять не нужно, т.к. FraudWall при построении актуального списка 550-П (639-П) использует только те XML-файлы, которые находятся на этом ресурсе на текущий момент.

    Импорт списков 550-П (639-П) начинается автоматически, как только завершилось копирование новых XML-файлов на этот сетевой ресурс.

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

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

    7.8.1. Использование списков 550-П (639-П)

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

    7.9. Импорт файлов фидов ФинЦЕРТ

    FraudWall может автоматически обрабатывать файлы фидов с реквизитами получателей, распространяемые ФинЦЕРТ ЦБ РФ в соответствии с частью 5 статьи 27 Федерального закона от 27 июня 2011 года "О национальной платежной системе" 161-ФЗ.

    Импорт таких файлов в FraudWall может быть осуществлен 3 способами:

    • через Web-интерфейс системы FraudWall "Аналитика по получателю"

    • путем отправки ZIP-файла на ящик fwblack@сервер_управления_FraudWall (аналогично рассылке "антидроп-клуба")

    • автоматически ежедневной загрузкой файлов фидов через API ФинЦЕРТ

    7.9.1. Импорт файла фида ФинЦЕРТ через Web-интерфейс FraudWall

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

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

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

    Примечание

    Файл фида обрабатывается в том виде, в котором его предоставил ФинЦЕРТ - т.е. в виде ZIP-файла. Предварительно извлекать из него CSV-файлы не требуется.

    7.9.2. Импорт файла фида ФинЦЕРТ через почтовое сообщение

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

    Примечание

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

    7.9.3. Автоматическая загрузка фидов через API ФинЦЕРТ

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

    Примечание

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

    Такой подход позволит визуально убедиться в корректности выгружаемых данных в ФинЦЕРТ.

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

    1. Скачать дистрибутив CryptoPro CSP с сайта компании - разработчика www.cryptopro.ru (необходима серверная версия 4.0, подверсия 9969 и выше, под операционную систему Linux архитектуры Intel 32 bit).Архивный файл дистрибутива CryptoPro CSP будет называться как linux-ia32.tgz

      Внимание

      Для установки CryptoPro CSP нельзя использовать штатную инструкцию, поставляемую в комплекте CryptoPro CSP. Процедура установки будет описана ниже.

    2. Записать данный файл на сервер управления FraudWall в директорию /tmp

    3. В SSH-консоли перейти в директорию /tmp и выполнить команду установки CryptoPro CSP: fw_cpro install

    4. Если в процессе установки возникли какие-либо проблемы, для удаления дистрибутива CryptoPro CSP используйте команду: fw_cpro uninstall и свяжитесь с технической поддержкой компании Фродекс.

    5. В CryptoPro CSP предусмотрен бесплатный ознакомительный период в несколько месяцев, в течение которого необходимо будет купить лицензию на CryptoPro CSP (серверная версия) в компании КриптоПро и указать ее командой: fw_cpro license

    6. Согласно документу "Краткая инструкция по организации взаимодействия с АСОИ ФинЦЕРТ с использованием API" через личный кабинет банка в ФинЦЕРТ необходимо запросить специальный логин и пароль для работы через API ФинЦЕРТ на тестовом сервере ФинЦЕРТ (он будет отличаться от того, под которым идет работа в личном кабинете банка).

    7. Укажите полученный от ФинЦЕРТ логин и пароль для работы с тестовым сервером ФинЦЕРТ в файле /etc/fraudwall/fincert/auth-test.json

    8. Выполните команду: fw_fincert -t

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

      Примечание

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

    9. Сообщите в личном кабинете ФинЦЕРТ о результате загрузки фидов с тестового сервера и запросите дополнительный логин и пароль для доступа через API на рабочий сервер ФинЦЕРТ.

    10. На сервере FraudWall в директории /etc/fraudwall/fincert скопируйте файл auth-test.json в auth.json и укажите в auth.json логин и пароль для подключения к рабочему серверу ФинЦЕРТ.

    11. Убедитесь в успешной загрузке файлов фидов с рабочего сервера ФинЦЕРТ командой: fw_fincert -f

    12. Ежедневная автоматическая загрузка фидов с рабочего сервера ФинЦЕРТ начнется после того, как будет создан файл auth.json и будет осуществляться примерно в 13 и 17 часов по московскому времени. По результатам загрузки фидов на пользователей с ролью администратор FraudWall будет отправлять соответствующее сообщение - либо успешная обработка, либо лог неуспешных запросов через API ФинЦЕРТ.

    8. Информирование о событиях в системе

    8.1. Информирование по SMTP-почте

    В системе FraudWall предусмотрено 2 типа SMTP-сообщений:

    • административные

    • при обнаружении подозрительного платежного поручения в системе ДБО

    Схема доставки SMTP-сообщений показана на рисунке:

    Рисунок 71. Схема доставки SMTP-сообщений

    Схема доставки SMTP-сообщений

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

    Все письма, попадающие на postfix, перенаправляются на внешний SMTP-сервер банка, IP адрес которого указан в параметре mail_server конфигурационного файла fraudwall.xml.

    Каждый пользователь, которому необходимо получать SMTP-сообщения, должен быть создан в WWW-интерфейсе системы. Почтовый SMTP-ящик пользователя указывается в параметре e-mail пользователя (см.рисунок):

    Рисунок 72. Конфигурирование SMTP-почтового ящика пользователя

    Конфигурирование SMTP-почтового ящика пользователя

    Каждый пользователь может иметь только один почтовый ящик.

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

    8.1.1. Формирование конфигурации postfix

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

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

    8.1.2. Журнал событий доставки SMTP-сообщений

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

    Пример 6. Пример записи по доставке одного SMTP-сообщения

    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), по которому можно отследить историю доставки почтового сообщения.

    8.1.3. Повторная отправка почты

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

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

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

    8.1.4. Особенности доставки административных SMTP-сообщений

    Административные сообщения формируются при наступлении следующих событий:

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

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

    • ошибки при выполнении системных процессов

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

    8.1.5. Особенности доставки SMTP-сообщений при обнаружении подозрительного платежного поручения

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

    • сотрудник службы безопасности

    • операционист бэк-офиса

    Обязательным условием получения SMTP-уведомления является наличие необходимых прав доступа, т.е.:

    • пользователь должен быть активным (т.е. не заблокированным и не удаленным)

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

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

    9. Мониторинг и самовосстановление системы

    9.1. Общие принципы

    В системе FraudWall предусмотрена система непрерывного мониторинга и автоматического самовосстановления на основе программного обеспечения monit .

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

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

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

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

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

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

    Реализованный механизм мониторинга системы обеспечивает непрерывность процесса самовосстановления системы в режиме 24x7.

    9.2. Журнал событий системы мониторинга

    Все события системы мониторинга фиксируются в файле журнала событий /var/log/monit.

    [16.04.2012 10:08:47 UTC] info     : Reinitializing monit daemon
    [16.04.2012 10:08:47 UTC] info     : monit: No daemon process found
    [16.04.2012 10:08:57 UTC] info     : Starting monit daemon with http interface at [*:2812]
    [16.04.2012 10:08:57 UTC] info     : Starting monit HTTP server at [*:2812]
    [16.04.2012 10:08:57 UTC] info     : monit HTTP server started
    [16.04.2012 10:08:57 UTC] info     : 'system' Monit instance changed (Monit started)
    [16.04.2012 10:09:07 UTC] error    : 'fwslave_process' Does not exist (process is not running)
    [16.04.2012 10:09:07 UTC] info     : 'fwslave_process' trying to restart
    [16.04.2012 10:09:07 UTC] info     : 'fwslave_process' start: /etc/init.d/fw_slave
    [16.04.2012 10:10:19 UTC] info     : 'fwslave_process' Exists (process is running with pid 4386)

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

    9.3. WWW-интерфейс системы мониторинга

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

    WWW-интерфейс системы мониторинга доступен по протоколу HTTP, TCP порт 2812 (пользователь admin, пароль admin).

    Несмотря на то, что WWW-интерфейс системы monit настроен в режиме «только для чтения», рекомендуется на межсетевых экранах разрешить доступ к этому порту только с компьютеров администраторов системы.

    9.4. Мониторинг серверов ДБО

    Помимо непрерывного мониторинга работоспособности компонент FraudWall, в системе предусмотрен также мониторинг работоспособности самой системы ДБО в целом.

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

    Примечание

    Так как в качестве исходных данных для анализа используется дамп трафика, мониторинг работоспособности ДБО осуществляется только для "тонкого" клиента ДБО.

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

    • задержки в сохранении файла дампа

    • общее время загрузки (UPLOAD) файла на сервер

    • максимальное время обработки HTTP-запроса WWW-сервером (первая страница, "быстрые" запросы, любой запрос)

    Вся конфигурация подсистемы мониторинга ДБО находится в файле /etc/fraudwall/diagnose.conf. Описание проверяемых параметров, а также пороговые значения для срабатывания приведены непосредственно в этом файле.

    9.4.1. Автоматическая диагностика проблем в ДБО

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

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

    Примечание

    Если на сервере системы ДБО в ночное время выполняются технологические работы, можно отключить формирование почтовых уведомлений в ночное время, указав в конфигурационном файле /etc/fraudwall/diagnose.conf в параметре email_options значение (будут проверяться только события с 9 до 18 часов местного времени):

    $email_options = "-t 09 18";

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

    Полный перечень параметров можно увидеть, выполнив команду fw_diagnose

    9.4.2. Диагностика проблем с ДБО в ручном режиме

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

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

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

    10. Обновление программного обеспечения

    10.1. Общие принципы

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

    • обновление программного обеспечения операционной системы

    • обновление программного обеспечения FraudWall

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

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

    • репозиторий RedHat - используется для обновления операционной системы RedHat Enterprise Linux

    • общебанковский репозиторий FraudWall - используется для обновлений программного обеспечения, используемого системой FraudWall для всех банков

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

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

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

    10.2. Информирование о необходимости установки обновлений

    Все сервера системы FraudWall автоматически (ежечасно) проверяют наличие обновлений на операционную систему и программное обеспечение системы FraudWall.

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

    10.3. Обновление программного обеспечения операционной системы

    10.3.1. Техническая поддержка на RedHat Enterprise Linux

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

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

    Внимание

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

    10.3.2. Установка обновлений на операционную систему в ручном режиме

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

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

    Примечание

    Без опции "-s" будет осуществляться обновление только программного обеспечения FraudWall.

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

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

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

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

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

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

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

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

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

    10.3.3. Установка обновлений на операционную систему в автоматическом режиме

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

    Внимание

    Указанные параметры необходимо сконфигурировать на каждом сервере.

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

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

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

    10.4. Обновление программного обеспечения системы FraudWall

    10.4.1. Техническая поддержка на систему FraudWall

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

    10.4.2. Установка обновлений на систему FraudWall в ручном режиме

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

    Внимание

    Указанные параметры необходимо сконфигурировать на каждом сервере.

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

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

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

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

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

    10.4.3. Установка обновлений на систему FraudWall в автоматическом режиме

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

    10.5. Механизм получения обновлений

    Получение (скачивание) обновлений осуществляется штатной утилитой yum по протоколу HTTP с WWW-серверов, находящихся в сети Интернет.

    В случае использования выделенного WWW-сервера обновлений, все обновления скачиваются централизованно и автоматически «публикуются» на WWW-сервере apache, являющейся частью программного обеспечения WWW-сервера обновлений. Поэтому, все остальные сервера могут забирать обновления не из сети Интернет, а непосредственно с сервера обновлений.

    При отсутствии выделенного WWW-сервера обновлений, каждый из серверов с системой FraudWall вынужден самостоятельно скачивать обновления из сети Интернет.

    10.5.1. Использование централизованного WWW-сервера обновлений

    Внимание

    Конфигурирование серверов FraudWall на централизованное получение обновлений можно только после завершения настройки WWW-сервера обновлений (раздел 4.9 «Установка WWW-сервера обновлений»).

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

    WWW-сервер обновлений автоматически скачивает обновления со следующей периодичностью:

    • обновления операционной системы - ежесуточно примерно в 8:00 и 20:00 временной зоны UTC (в 12:00 и 24:00 московского времени соответственно)

    • обновления программного обеспечения FraudWall - ежечасно

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

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

    10.5.2. Конфигурирование получения обновлений в проксированном режиме

    Внимание

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

    Если взаимодействие с Интернет осуществляется через 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

    11. Интеграция FraudWall с информационными системами банка

    11.1. Общее описание интеграции

    11.1.1. С какими системами банка и для каких целей требуется интеграция

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

    Таблица 19. Источники данных

    тип информациивозможные источники
    реквизиты платежных поручений, создаваемых посредством систем ДБОбаза данных ДБО, база данных АБС
    реквизиты платежных поручений, создаваемых сотрудниками банка в системе АБСбаза данных АБС
    дамп трафика работы клиентов в системе ДБО, поступающего на WWW-сервер банкаWWW-сервер ДБО
    история исполненных в АБС платежных поручений клиентовбаза данных ДБО, база данных АБС
    реквизиты платежных поручений, поступающих из других банковбаза данных АБС
    информацию о счетах клиенте банка (перечне его счетов и текущем остатке на счете)база данных ДБО, база данных АБС
    контактную информацию о клиенте банка (ФИО, должность и контактный телефон представителей клиента (директор, гл.бухгалтер и т.д.)база данных ДБО, база данных АБС, база данных CRM
    информацию о наличии вредоносной активности на стороне компьютера клиентаоблачные решения Kaspersky Fraud Prevention Cloud, Group-IB Bot-Trek Secure Bank, IBM Trusteer Pinpoint Malware Detection

    Примечание

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

    Например, информация о наличии вредоносной активности на стороне компьютера клиента требует интеграции с дополнительными решениями от компаний Group-IB, Kaspersky Labs или IBM Trusteer. Если такие решения в банке не внедрялись, FraudWall принимает решение о подозрительности платежа по оставшимся доступным ему данным.

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

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

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

    • из дампа трафика на стороне WWW-сервера банка

    • из VIEW fraudwall_doc (в режиме анализа платежей во VIEW fraudwall_doc, см. 11.11 «fraudwall_doc. Получение платежей для анализа»)

    • из fraudwall_alert (в режиме анализа платежей в таблице fraudwall_alert)

    • из HTTP/HTTPS-запроса внешней системы

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

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

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

    • информация об IP адресе, с которого была сессия клиента

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

    • информация от систем, выявляющих вредоносную активность на стороне компьютера клиента

    • информация о доступных средствах на счету клиента в момент создания платежа

    • и т.д.

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

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

    • статус обработки платежного поручения - является ли оно подозрительным или нет, нужно ли приостановить его дальнейшее исполнение в АБС

    • информирование сотрудников банка о подозрительных событиях - например, подозрительное изменение паспортных данных клиента и т.д.

    • звонок клиенту для подтверждения подозрительного платежа (общение осуществляется полностью в автоматизированном режиме с помощью сервера синтеза и распознавания речи)

    11.1.2. Остановка подозрительных платежей

    11.1.2.1. Доработка АБС

    Примечание

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

    АБС должна выполнять следующие операции:

    • (только при интеграции в режиме анализа платежей в таблице fraudwall_alert) помещать в эту таблицу все платежи, подлежащие проверке, со значением поля статуса, равным "X".

    • блокировать исполнение платежей, реквизиты которых есть в таблице fraudwall_alert, но статус отличен от "g" или "G"

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

    • при открытии в интерфейсе АБС платежа, реквизиты которого есть в таблице fraudwall_alert со статусом "j", выводить на экран алерт с текстом: «Платеж не может быть проведен в АБС, т.к. находится на визуальном контроле в системе FraudWall» (или другой схожий по смыслу текст). Без возможности изменить статус в АБС.

    • при открытии в интерфейсе АБС платежа, реквизиты которого есть в таблице fraudwall_alert со статусом "S", выводить на экран соответствующее сообщение с краткой инструкцией для операциониста - что говорить клиенту, куда обращаться при подтверждении мошеннического платежа, об ответственности операциониста и т.д.С возможностью изменить статус в АБС.

    • запрашивать у операциониста текстовый комментарий с результатами общения с клиентом при изменении статуса в АБС сотрудником банка

    • хранить комментарий в журнале аудита действий сотрудника банка

    • в зависимости от результата общения с клиентом, выставлять статус (G - "создан клиентом", F - "мошеннический", R - "отказан в исполнении, но не мошеннический") в таблице fraudwall_alert для соответствующего платежа (кроме платежей со статусом "j")

    Если для сайта указан способ диагностики работоспособности АБС с помощью тестового платежного поручения (см. 11.1.2.4 «Обеспечение надежности механизма интеграции с АБС»), для записи в таблице fraudwall_alert со значением docid, равным 0, выставлять статус "G" (этот статус необходимо выставлять каждый раз, т.к. через некоторое время FraudWall сбрасывает статус такому документу).

    11.1.2.2. Конфигурирование FraudWall

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

    Примечание

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

    Примечание

    К АБС устанавливает соединение только сервер управления системы FraudWall.

    Подключение к базе данных АБС осуществляется посредством механизма ODBC. Процедура установки и конфигурирования ODBC-драйверов приведена в разделе 12.4 «Установка ODBC-драйверов».

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

    Рисунок 74. Параметры для интеграции с АБС

    Параметры для интеграции с АБС

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

    Журнал событий работы с базой данных АБС находится в файле /var/log/fraudwall/fw_control.log.

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

    11.1.2.3. Автоматическое очищение старых записей в fraudwall_alert

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

    Рисунок 75. Срок хранения записей в таблице fraudwall_alert

    Срок хранения записей в таблице fraudwall_alert

    11.1.2.4. Обеспечение надежности механизма интеграции с АБС

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

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

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

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

    • простой способ проверки

    • расширенный (с помощью тестового платежного поручения)

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

    Расширенный способ проверки предусматривает не только ежечасную проверку по предыдущему способу, но и создание в таблице fraudwall_alert тестового подозрительного платежного поручения (со статусом "S") каждые 10 минут. В свою очередь, АБС должна при очередном сканировании таблицы fraudwall_alert этой тестовой записи выставить статус "G". Если через 10 минут статус не был обновлен системой АБС, FraudWall считает, что механизм блокирования платежных поручений в АБС неработоспособен, и отсылает администратору соответствующее почтовое сообщение. Такой способ позволяет ускорить обнаружение проблем в АБС, но требует небольших дополнительных доработок в АБС.

    11.1.3. Типовой подход к интеграции на этапе тестирования системы

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

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

    11.1.3.1. Работы, которые необходимо выполнить по завершению этапа тестирования

    После успешного завершения этапа тестирования системы FraudWall и принятия решения о внедрении системы, необходимо реализовать механизм торможения платежей (см. раздел 11.1.2 «Остановка подозрительных платежей»).

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

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

    11.1.4. Снижение нагрузки на сервер анализируемой базы данных

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

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

    11.2. Варианты интеграции FraudWall с системами банка

    11.2.1. Анализ платежей из VIEW fraudwall_doc

    Преимущества:

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

    • процедура торможения подозрительных платежей проще в реализации по сравнению с вариантом 11.2.2 «Анализ платежей из таблицы fraudwall_alert (по принципу "вопрос - ответ")»

    Недостатки по сравнению с вариантом 11.2.2 «Анализ платежей из таблицы fraudwall_alert (по принципу "вопрос - ответ")»:

    • В некоторых системах получение данных через VIEW fraudwall_doc может являться "тяжелым" запросом.

    • Если АБС обрабатывает в fraudwall_alert только платежи, вызвавшие подозрение, есть вероятность того, что FraudWall не успеет выгрузить результат проверки до того, как платеж будет исполнен в АБС (например, если сервер FraudWall выключен). Поэтому необходимо реализовать, чтобы АБС ждала от FraudWall статус по каждому платежу, даже если он не вызвал подозрение. Это может привести к дополнительной нагрузке на АБС

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

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

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

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

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

    11.2.1.1. Настройка на стороне анализируемой базы данных

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

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

    • создать пользователя, под которым FraudWall будет подключаться к базе данных

    • создать набор VIEW в соответствии с требованиями настоящего раздела

    • предоставить созданному пользователю доступ с правом SELECT для работы VIEW

    • создать индексы (при необходимости), ускоряющие работу запросов типа SELECT FROM VIEW

    Примечание

    Примеры SQL-команд для интеграции с различными системами ДБО под разные СУБД находятся в директории /usr/share/doc/fraudwall на сервере управления. Если вы затрудняетесь самостоятельно создать необходимые VIEW, обратитесь в службу технической поддержки.

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

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

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

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

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

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

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

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

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

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

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

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

    11.2.2. Анализ платежей из таблицы fraudwall_alert (по принципу "вопрос - ответ")

    Преимущества:

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

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

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

    • без реализации в АБС или ДБО механизма выгрузки платежа в таблицу fraudwall_alert невозможно начать тестирование системы FraudWall.

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

    Внимание

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

    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.

    11.2.3. Анализ платежей по HTTP/HTTPS-запросу (по принципу "вопрос - ответ")

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

    11.2.4. Анализ WWW-трафика

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

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

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

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

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

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

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

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

    11.2.4.1. Интеграция в случае установки модуля BSI системы BS-Client на сервере FraudWall

    Примечание

    При интеграции с ДБО BS-Client "Интернет-клиент" данный вариант является предпочтительным

    Одним из вариантов интеграции системы FraudWall заключается в установке модуля BSI ДБО BS-Client непосредственно на тот же WWW-сервер apache, где уже установлен модуль hGuard системы FraudWall.

    В этом случае модуль BSI системы BS-Client (а следовательно, и вся система ДБО BS-Client) работает непосредственно с IP-адресом клиента в сети Интернет, тем самым позволяя фильтровать клиента по внешнему IP-адресу.

    Со стороны системы ДБО BSClient, модуль BSI, установленный на сервере системы FraudWall, полностью соответствует требованиям раздела «Настройка параметров взаимодействия компонентов при использовании веб-сервера Apache» документации по системе BSClient.

    Формирование всех конфигурационных файлов (apache, mod_jk, tomcat и т.д.), указанных в документации по системе BSClient, осуществляется автоматически на основе параметров, указанных в настройках сайта конфигурации системы FraudWall. Вручную необходимо только сформировать bsi.xml, а также скопировать bsi.jar и файлы www-сервера (детали в разделе 4.8.1 «Установка модуля BSI на сервер FraudWall (предварительный этап)»).

    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-сервером системы ДБО.

    11.3. fraudwall_learn. Получение платежей, исполненных в АБС

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

    11.3.1. Описание полей структуры fraudwall_learn

    Таблица 20. Перечень полей fraudwall_learn

    ПолеТип данныхОписание
    updatedДАТА ВРЕМЯ

    Дата и время исполнения документа в АБС.

    Примечание

    Если есть проблемы с нагрузкой на СУБД при работе с данной VIEW, это поле может содержать только дату (без учета времени), т.е. часы, минуты и секунды всегда равны 00:00:00

    abs_dateДАТА ВРЕМЯ

    дата исполнения платежа в АБС

    Примечание

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

    deviceтекст

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

    Наименование идентификаторов: mac - MAC-адрес сетевой карты, appid - уникальный ID моб. приложения на моб. устройстве, serial-number - уникальный серийный номер моб. аппарата, imei - IMEI-номер моб. устройства, imsi - IMSI-номер SIM-карты, iccid - уникальный идентификационный номер SIM-карты в международном формате. Если у Вашей системы ДБО есть также свой цифровой отпечаток устройства клиента, необходимо сообщить об этом нам, м.б. выделено уникальное наименование идентификатора

    Примечание

    Пример такой строки:

    mac="00:11:22:33:44:55" mac="00:11:22:33:44:66" imei="123456789012345"

    docidтекст или числоИдентификатор документа в анализируемой системе
    docnumberтекст или число Поле документа «Номер документа».
    docdateДАТА ВРЕМЯ Поле документа «Дата документа».

    Внимание

    Обратите внимание, что тип данных этого поля - ДАТА ВРЕМЯ

    from_idтекст или число

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

    Примечание

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

    from_nameтекстПоле документа «Наименование плательщика»
    from_innтекстПоле документа «ИНН плательщика»
    from_accountтекстПоле документа «расчетный счет плательщика»
    from_bicтекстПоле документа «БИК банка плательщика»
    from_bankтекст

    Наименование банка, соответствующего БИК банка плательщика

    Примечание

    Можно всегда возвращать NULL - в этом случае значение будет браться из встроенного справочника банков РФ

    from_cityтекст

    Город, соответствующий банку плательщика

    Примечание

    Можно всегда возвращать NULL - в этом случае значение будет браться из встроенного справочника банков РФ

    to_idтекст или число

    Идентификатор клиента в анализируемой системе, которому принадлежит расчетный счет получателя

    Примечание

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

    to_nameтекстПоле документа «Наименование получателя»
    to_innтекстПоле документа «ИНН получателя»
    to_accountтекстПоле документа «расчетный счет получателя»
    to_bicтекстПоле документа «БИК банка получателя»
    to_bankтекст

    Наименование банка, соответствующего БИК банка получателя

    Примечание

    Можно всегда возвращать NULL - в этом случае значение будет браться из встроенного справочника банков РФ

    to_cityтекст

    Город, соответствующий банку получателя

    Примечание

    Можно всегда возвращать NULL - в этом случае значение будет браться из встроенного справочника банков РФ

    currencyтекст или число

    3-х буквенный или 3-х числовой код валюты платежа

    amountчисло с 2 знаками после запятой

    Поле документа «Сумма платежа» (в валюте currency)

    Примечание

    При отсутствии или пустом значении поля currency валюта платежа берется из 20-значного счета получателя, а при его отсутствии - из 20-значного счета плательщика

    purposeтекстПоле документа «Назначение платежа»
    kbkтекст20-значный код КБК (заполняется только для бюджетных платежей, у остальных платежей – значение NULL)
    from_phoneтекст

    Значение идентификатора телефона плательщика. Поле необязательное (нужно только если проверяются и операции СБП). Если операция не СБП - может быть NULL.

    Примечание

    Пример: 0079101234567 (из ЭБД {21} формата сообщения СБП (в случае ЭБД {46}= MTEL))

    to_phoneтекст

    Значение идентификатора телефона получателя. Поле необязательное (нужно только если проверяются и операции СБП). Если операция не СБП - может быть NULL.

    Примечание

    Пример: 0079101234567 (из ЭБД {20} формата сообщения СБП (в случае ЭБД {47}= MTEL))

    to_paygate_dboidтекстИдентификатор поставщика услуг в ДБО (цифровой идентификатор уникальной связки "поставщик услуги -тип услуги" (например, идентификаторы для услуг Ростелеком-интернет, Ростелеком-телевидение и т.д.)) - опционально, значение может быть пустым
    to_paygate_accountтекстНомер лицевого счета, номер кошелька, номер телефона или иной идентификатор клиента в системе поставщика услуг - опционально, значение может быть пустым

    11.3.2. Проверка, поддерживает ли поле UPDATED часы, минуты и секунды

    Назначение:

    Данный запрос проверяет, поддерживает ли поле 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 их поддерживает.

    11.3.3. Получение реквизитов платежей, исполненных в АБС за текущий день

    Назначение:

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

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

    При выполнении хотя бы одного запроса, 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 получает информацию из анализируемой системы через VIEW fraudwall_learn, эту сортировку FraudWall автоматически добавляет при вызове SELECT, поэтому в коде VIEW fraudwall_learn сортировку добавлять не нужно.

    Примечание

    Обратите внимание, что для целей проверки платежей на ПОД/ФТ необходимо, чтобы возвращались не только платежи от клиентов банка, но и платежи на клиентов банка, в т.ч. получаемые из других банков.

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

    Назначение:

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

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

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

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

    • при автоматическом дообучении новыми исполненными платежами в процессе эксплуатации системы

    При выполнении хотя бы одного запроса, 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

    Примечание

    Если FraudWall получает информацию из анализируемой системы через VIEW fraudwall_learn, эту сортировку FraudWall автоматически добавляет при вызове SELECT, поэтому в коде VIEW fraudwall_learn сортировку добавлять не нужно.

    Примечание

    Обратите внимание, что для целей проверки платежей на ПОД/ФТ необходимо, чтобы возвращались не только платежи от клиентов банка, но и платежи на клиентов банка, в т.ч. получаемые из других банков.

    11.4. fraudwall_client. Получение информации о клиентах банка

    fraudwall_client используется для получения информации о клиенте банка.

    11.4.1. Описание полей структуры fraudwall_client

    Таблица 21. Перечень полей fraudwall_client

    ПолеТип данныхОписание
    idтекст или числоID клиента банка в анализируемой системе
    client_typeчисло

    Возвращает следующее значение в зависимости от типа клиента: 1 - юридическое лицо или ИП, 2 - физическое лицо, 3 - банк.

    Примечание

    Если эта информация в анализируемой системе отсутствует, возвращайте всегда значение "1". FraudWall автоматически скорректирует тип клиента на основании других данных (формату ИНН, р/с и т.д.)

    residentчислоВозвращает следующее значение в зависимости от типа клиента: 1 - резидент, 0 - нерезидент
    nameтекст Полное наименование клиента (для юридического лица или ИП) или Фамилия Имя Отчество (для физического лица)
    name_shortтекст Краткое наименование клиента - юридического лица. Для физического лица нужно возвращать пустое значение.
    innтекстИНН клиента
    date_openДАТА ВРЕМЯ

    Дата регистрации юридического лица или ИП, NULL для физического лица

    Внимание

    Обратите внимание, что тип данных этого поля - ДАТА ВРЕМЯ

    date_bornДАТА ВРЕМЯ

    Дата рождения для физического лица или ИП , NULL для юридического лица.

    Внимание

    Обратите внимание, что тип данных этого поля - ДАТА ВРЕМЯ

    addressтекстюридический адрес (для юридических лиц) либо адрес регистрации (для физических лиц). Если не известен, можно возвращать пустую строку.
    address_realтекстфактический адрес клиента. Если не известен, можно возвращать пустую строку
    address_postтекстпочтовый адрес клиента. Если не известен, можно возвращать пустую строку
    doc_nameтекстнаименование документа, удостоверяющего личность (для клиентов - физических лиц или ИП). Если не известен, можно возвращать пустую строку
    doc_seriaтекстсерия документа, удостоверяющего личность (для клиентов - физических лиц или ИП). Если не известен, можно возвращать пустую строку.
    doc_numтекстномер документа, удостоверяющего личность (для клиентов - физических лиц или ИП). Если не известен, можно возвращать пустую строку
    doc_dateДАТА ВРЕМЯ

    Дата выдачи документа, удостоверяющего личность, NULL если не известен

    Внимание

    Обратите внимание, что тип данных этого поля - ДАТА ВРЕМЯ

    okpoтекстКод ОКПО
    startamountчислоРазмер уставного капитала
    okvedтекстОсновной и дополнительные коды ОКВЭД, объединенные через "," в виде одной строки
    badcountryчислоУровень риска по стране, в которой зарегистрирован клиент. Возможные значения: 0 - нет данных, 1 - низкий, 2 - средний (или повышенный), 3 - высокий, 4 - критичный
    badagentcountryчислоПризнак того, что ранее клиент делал платежи в страны высокого риска. «0»-Нет данных, «1»- Низкий, «2»-Средний (или повышенный), «3»- Высокий, «4»- Критичный.
    badpayчислоУровень риска, связанного с проведением клиентом определенного вида операций. «0»-Нет данных, «1»-Низкий, «2»- Средний (или повышенный), «3»- Высокий, «4»- Критичный.
    badclienttypeчислоУровень риска по типу клиента и (или) бенефициарного владельца. «0»-Нет данных, «1»-Низкий, «2»- Средний (или повышенный), «3»- Высокий, «4»- Критичный.
    pdlчислоПринадлежность к ПДЛ (1 – принадлежит, 0 – не принадлежит) Если в АБС признаки ПДЛ разделены на РПДЛ/ИПДЛ/МПДЛ(ДЛМО), то следует указывать значения «2» – для РПДЛ, «3» – для ИПДЛ, «4» – для МПДЛ (ДЛМО).
    familypdlчислоПринадлежность к родственникам ПДЛ (1 – принадлежит, 0 – не принадлежит). Если в АБС признаки ПДЛ разделены на РПДЛ/ИПДЛ/МПДЛ(ДЛМО), то следует указывать значения «2» – для РПДЛ, «3» – для ИПДЛ, «4» – для МПДЛ (ДЛМО).
    emp_countчислоШтатная (среднесписочная) численность клиента - юридического лица. Для физ.лиц – NULL.
    amlscoreчисло (с плавающей запятой)Уровень подозрительности клиента по ПОД/ФТ по данным из АБС/ДБО (скоринговый балл по клиенту из АБС). Создается в случае необходимости. Если данных нет можно возвращать NULL. По тем клиентам у которых есть значение - возвращать любое значение больше или равно 0.
    amltextтекстТекстовая расшифровка уровня подозрительности клиента по ПОД/ФТ по данным из АБС/ДБО (статус ФМ по клиенту из АБС). Создается в случае необходимости. Если данных нет можно возвращать NULL.
    salaryчислоПризнак того, что клиент - ФЛ получает заработную плату на свой счет открытый в Банке. "0" - нет данных, "1" - зарплатный клиент. Поле является необязательным.
    dbolimit_opтекст или число (с двумя знаками после запятой)Значение лимита (сумма в рублевом эквиваленте) для одной операции по списанию д/с в ДБО (если есть только карточный лимит и лимит по счету, то можно возвращать минимальный из них). Если данных нет можно возвращать NULL. Если VIEW создается в БД ДБО, то данное поле желательно создать, в БД АБС - не обязательно.
    dbolimit_dayтекст или число (с двумя знаками после запятой)Значение лимита (сумма в рублевом эквиваленте) по сумме операций по списанию д/с в ДБО за день (если есть только карточный лимит и лимит по счету, то можно возвращать минимальный из них). Если данных нет, то можно возвращать NULL. Если VIEW создается в БД ДБО, то данное поле желательно создать, в БД АБС - не обязательно.

    Примечание

    Поля okpo, startamount, okved, badcountry, badagentcountry, badpay, badclienttype, pdl, familypdl, emp_count, amlscore, amltext необходимо создавать только для целей ПОД/ФТ (при наличии лицензии FraudWall AML). В остальных случаях создание этих полей не обязательно.

    11.4.2. Первоначальное получение перечня ID клиентов для загрузки

    Назначение:

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

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

    Раз в сутки

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

    Отсутствуют

    Примечание

    Если FraudWall получает информацию из анализируемой системы через VIEW fraudwall_client в базе Microsoft SQL Server, в SELECT также добавляется WITH(NOLOCK), исключая тем самым блокировку таблиц анализируемой системы.

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

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

    Примечание

    Если FraudWall получает информацию из анализируемой системы через VIEW fraudwall_client, эту сортировку FraudWall автоматически добавляет при вызове SELECT, поэтому в коде VIEW fraudwall_client сортировку добавлять не нужно.

    11.4.3. Получение перечня последующих ID клиентов

    Назначение:

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

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

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

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

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

    Примечание

    Если FraudWall получает информацию из анализируемой системы через VIEW fraudwall_client в базе Microsoft SQL Server, в SELECT также добавляется WITH(NOLOCK), исключая тем самым блокировку таблиц анализируемой системы.

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

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

    Примечание

    Если FraudWall получает информацию из анализируемой системы через VIEW fraudwall_client, эту сортировку FraudWall автоматически добавляет при вызове SELECT, поэтому в коде VIEW fraudwall_client сортировку добавлять не нужно.

    11.4.4. Получение информации о заданном клиенте

    Назначение:

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

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

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

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

    id = ID клиента

    Примечание

    Если FraudWall получает информацию из анализируемой системы через VIEW fraudwall_client в базе Microsoft SQL Server, в SELECT также добавляется WITH(NOLOCK), исключая тем самым блокировку таблиц анализируемой системы.

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

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

    11.5. fraudwall_balance. Получение счетов клиента и суммы остатка на них

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

    11.5.1. Описание полей структуры fraudwall_balance

    Таблица 22. Перечень полей fraudwall_balance

    ПолеТип данныхОписание
    idтекст или числоID клиента банка в анализируемой системе
    accountтекст

    20-ти значный счет клиента

    bicтекстБИК банка, в котором открыт данный счет
    amountтекст или число Сумма остатка на счете клиента в валюте счета (NULL, если неизвестно).
    amountrubтекст или число Сумма остатка на счете клиента в рублевом эквиваленте (NULL, если неизвестно).
    date_openДАТА ВРЕМЯ

    Дата открытия счета в банке (NULL, если не известно)

    Внимание

    Обратите внимание, что тип данных этого поля - ДАТА ВРЕМЯ

    date_closeДАТА ВРЕМЯ

    Дата закрытия счета в банке (NULL, если счет не закрыт)

    Внимание

    Обратите внимание, что тип данных этого поля - ДАТА ВРЕМЯ

    time_whenДАТА ВРЕМЯ

    Время, на которое была сохранена информация об остатке на счете

    Примечание

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


    11.5.2. Получение остатка на заданном счете

    Назначение:

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

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

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

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

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

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

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

    Примечание

    Если FraudWall получает информацию из анализируемой системы через VIEW fraudwall_balance в базе Microsoft SQL Server, в SELECT также добавляется WITH(NOLOCK), исключая тем самым блокировку таблиц анализируемой системы.

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

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

    Примечание

    Если FraudWall получает информацию из анализируемой системы через VIEW fraudwall_balance, эту сортировку FraudWall автоматически добавляет при вызове SELECT, поэтому в коде VIEW fraudwall_balance сортировку добавлять не нужно.

    11.5.3. Получение информации о всех счетах заданного клиента

    Назначение:

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

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

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

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

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

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

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

    Примечание

    Если FraudWall получает информацию из анализируемой системы через VIEW fraudwall_balance в базе Microsoft SQL Server, в SELECT также добавляется WITH(NOLOCK), исключая тем самым блокировку таблиц анализируемой системы.

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

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

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

    2. По возрастанию значения поля date_open

    3. По возрастанию значения поля bic

    4. По возрастанию значения поля account

    Примечание

    Если FraudWall получает информацию из анализируемой системы через VIEW fraudwall_balance, эту сортировку FraudWall автоматически добавляет при вызове SELECT, поэтому в коде VIEW fraudwall_balance сортировку добавлять не нужно.

    11.6. fraudwall_contact. Получение контактной информации о клиенте

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

    11.6.1. Описание полей структуры fraudwall_contact

    Таблица 23. Перечень полей fraudwall_contact

    ПолеТип данныхОписание
    idтекст или числоID клиента банка в анализируемой системе
    innтекстИНН клиента
    addressтекстФактический адрес клиента
    companyтекст

    Наименование организации

    Примечание

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

    fioтекст

    Фамилия Имя Отчество клиента (если клиент - физическое лицо) либо представителя клиента - юридического лица

    Примечание

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

    titleтекст

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

    phoneтекст

    Строка с телефонами для связи с клиентом. Можно указать несколько телефонов через запятую.

    Примечание

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

    birthdayДАТА ВРЕМЯ

    Дата рождения клиента - физического лица.

    Примечание

    Для клиентов - юридических лиц можно всегда возвращать NULL

    Обратите внимание, что формат этого поля - ДАТА ВРЕМЯ

    infotextтекстТекст, который дополнительно нужно выводить вместе с телефоном (например, контрольный вопрос/ответ и т.д.). Допускаются переводы строки в тексте. Если дополнительный текст выводить не нужно, можно всегда возвращать пустую строку
    infohtmlтекстHTML-текст, который дополнительно нужно выводить вместе с телефоном. Если дополнительный текст выводить не нужно, можно всегда возвращать пустую строку

    11.6.2. Получение контактов клиента на основе его ID

    Назначение:

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

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

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

    • при открытии в интерфейсе FraudWall деталей платежного поручения

    • при начале дозвона системой FraudInform по подозрительному платежному поручению клиента

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

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

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

    Примечание

    Если FraudWall получает информацию из анализируемой системы через VIEW fraudwall_contact в базе Microsoft SQL Server, в SELECT также добавляется WITH(NOLOCK), исключая тем самым блокировку таблиц анализируемой системы.

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

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

    11.6.3. Получение контактов клиента на основе его ИНН

    Назначение:

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

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

    Данный запрос выполняется, если невозможно получить контактные данные на основе ID клиента (см. 11.6.2 «Получение контактов клиента на основе его ID») только для клиентов - юридических лиц и индивидуальных предпринимателей в следующих случаях:

    • при открытии в интерфейсе FraudWall деталей платежного поручения

    • при начале дозвона системой FraudInform по подозрительному платежному поручению клиента

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

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

    Примечание

    Если FraudWall получает информацию из анализируемой системы через VIEW fraudwall_contact в базе Microsoft SQL Server, в SELECT также добавляется WITH(NOLOCK), исключая тем самым блокировку таблиц анализируемой системы.

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

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

    11.7. fraudwall_contact_doc. Получение контактной информации о создателе платежа

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

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

    Для получения информации о контактах таких сотрудников и предусмотрена fraudwall_contact_doc.

    Примечание

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

    11.7.1. Описание полей структуры fraudwall_contact_doc

    Таблица 24. Перечень полей fraudwall_contact_doc

    ПолеТип данныхОписание
    docidтекст или числоИдентификатор документа в анализируемой базе данных
    time_whenДАТА ВРЕМЯДата и время, когда данный сотрудник работал с документом, NULL если неизвестно
    addressтекстФактический адрес клиента
    companyтекст

    Наименование организации

    Примечание

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

    fioтекст

    Фамилия Имя Отчество клиента (если клиент - физическое лицо) либо представителя клиента - юридического лица

    Примечание

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

    titleтекст

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

    phoneтекст

    Строка с телефонами для связи с клиентом. Можно указать несколько телефонов через запятую.

    Примечание

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

    birthdayДАТА ВРЕМЯ

    Дата рождения клиента - физического лица.

    Примечание

    Для клиентов - юридических лиц можно всегда возвращать NULL

    Обратите внимание, что формат этого поля - ДАТА ВРЕМЯ

    infotextтекстТекст, который дополнительно нужно выводить вместе с телефоном (например, контрольный вопрос/ответ и т.д.). Допускаются переводы строки в тексте. Если дополнительный текст выводить не нужно, можно всегда возвращать пустую строку
    infohtmlтекстHTML-текст, который дополнительно нужно выводить вместе с телефоном. Если дополнительный текст выводить не нужно, можно всегда возвращать пустую строку

    11.7.2. Получение контактов клиента на основе ID документа

    Назначение:

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

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

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

    • при открытии в интерфейсе FraudWall деталей платежного поручения

    • при начале дозвона системой FraudInform по подозрительному платежному поручению клиента

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

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

    Примечание

    Если FraudWall получает информацию из анализируемой системы через VIEW fraudwall_contact_doc в базе Microsoft SQL Server, в SELECT также добавляется WITH(NOLOCK), исключая тем самым блокировку таблиц анализируемой системы.

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

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

    11.8. fraudwall_clientref. Получение информации о связях клиента банка

    fraudwall_clientref используется для получения информации о связях данного клиента банка с другими клиентами банка (например, "юридическое лицо - его учредитель").

    Примечание

    fraudwall_clientref используется только в FraudWall AML. Если требуется только проверка на кражу средств, создавать fraudwall_clientref не нужно.

    11.8.1. Описание полей структуры fraudwall_clientref

    Таблица 25. Перечень полей fraudwall_clientref

    ПолеТип данныхОписание
    idтекст или числоID клиента банка в анализируемой системе
    refidтекст или число

    ID связанного клиента

    reftypeчисло

    Тип связи:

    1 - бенефициарный владелец (бенефициар)

    2 - выгодоприобретатель

    3 - представитель

    4 - учредитель

    5 - акционер

    6 - материнская компания

    7 - место работы

    8 - семейные отношения (родственник)

    9 - лицо с правом первой подписи

    10 - лицо с правом второй подписи


    11.8.2. Получение связей заданного клиента

    Назначение:

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

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

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

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

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

    Примечание

    Если FraudWall получает информацию из анализируемой системы через VIEW fraudwall_contact в базе Microsoft SQL Server, в SELECT также добавляется WITH(NOLOCK), исключая тем самым блокировку таблиц анализируемой системы.

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

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

    11.9. fraudwall_alert. Получение и выгрузка результатов проверки платежей

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

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

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

    В зависимости от настроек сайта, FraudWall может выгружать в эту таблицу:

    • только платежи, вызвавшие подозрение

    • все платежи, обработанные FraudWall

    При интеграции по принципу "вопрос - ответ" (см. 11.2.2 «Анализ платежей из таблицы fraudwall_alert (по принципу "вопрос - ответ")»), в эту таблицу платежи помещает не FraudWall, а система банка (ДБО или АБС).

    В любом случае, после проверки платежа для каждой записи в таблице fraudwall_alert система FraudWall всегда проставляет соответствующее непустое значение в поле status.

    Рисунок 83. Механизм остановки подозрительного платежа

    Механизм остановки подозрительного платежа

    Примечание

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

    Перед исполнением платежного документа, АБС должна проверить – есть ли данный документ в таблице fraudwall_alert, а если есть – какое значение имеет поле «статус». Например, если статус документа «подозрительный», АБС должна прекратить исполнение платежного документа и выдать соответствующее сообщение вида «документ подозрительный, требуется подтверждение клиентом».

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

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

    fraudwall_alert является интеграционной таблицей и используется в следующих случаях:

    • получение платежей для анализа (в режиме анализа таблицы fraudwall_alert)

    • выгрузку результатов проверки платежа (как в режиме анализа таблицы fraudwall_alert, так и в режиме анализа VIEW fraudwall_doc)

    • импорт в FraudWall статуса платежа, выставленного в интерфейсе ДБО или АБС

    11.9.1. Статусы платежа

    Примечание

    Статус в таблице fraudwall_alert может быть изменен как системой FraudWall, так и системой АБС или ДБО (для удобства по тексту будет написано, что статус выставляет АБС).

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

    • S (статус выставляется FraudWall) - платеж является подозрительным и его нельзя исполнять

    • F (статус выставляется АБС) - документ является мошенническим, в интерфейсе АБС сотрудник банка выставил статус "мошеннический" и АБС меняет статус на «F», а FraudWall еще не знает об этом

    • f (статус выставляется FraudWall) - документ является мошенническим, FraudWall знает об этом (либо он поменял статус "F" на "f" при обучении, либо статус изначально был выставлен в интерфейсе FraudWall)

    • G (статус выставляется АБС) - клиент подтвердил, что платеж не является мошенническим, он исполнен в АБС, и АБС меняет статус документа на "G", а FraudWall еще не знает об этом

    • g (статус выставляется FraudWall) - исполненный в АБС платеж не является мошенническим, FraudWall знает об этом (либо он поменял статус "G" на "g" при обучении, либо статус изначально был выставлен в интерфейсе FraudWall)

    • R (статус выставляется АБС) - клиент подтвердил, что платеж не является мошенническим, но по каким-либо причинам платежу было отказано в исполнении (например, нет средств на счету клиента, документ отозван и т.д.). АБС меняет статус документа на "R", а FraudWall еще не знает об этом

    • r (статус выставляется FraudWall) - отказанный в исполнении платеж не является мошенническим, FraudWall знает об этом (либо он поменял статус "R" на "r" при обучении, либо статус изначально был выставлен в интерфейсе FraudWall)

    • X (статус выставляется АБС) - система FraudWall должна проверить этот документ (см. 11.2.2 «Анализ платежей из таблицы fraudwall_alert (по принципу "вопрос - ответ")»).

    • J (статус выставляется АБС) – сотрудник банка при работе в АБС посчитал, что платеж должен быть остановлен по причинам ПОД/ФТ (или по иным причинам, не связанным с подозрением на кражу средств (например, визуальная проверка целевого использования кредитных средств и т.д.)). В дальнейшем работа с этим документом должна осуществляться только в интерфейсе FraudWall.

    • j (статус выставляется FraudWall) – платеж остановлен по причинам ПОД/ФТ (или по иным причинам, не связанным с подозрением на кражу средств (например, визуальная проверка целевого использования кредитных средств и т.д.)). Этот статус можно поменять только в интерфейсе системы FraudWall и он не может быть изменен в интерфейсе АБС, т.е. платежи со статусом "j" не могут быть проведены в АБС.

    11.9.2. Рекомендации по созданию таблицы fraudwall_alert

    Примечание

    Примеры SQL-команд для создания таблицы под разные СУБД находятся в директории /usr/share/doc/fraudwall на сервере FraudWall.

    11.9.2.1. Где создается таблица

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

    • создать пользователя, под которым FraudWall будет подключаться к базе данных

    • создать таблицу fraudwall_alert, владельцем которого является созданный пользователь

    • предоставить пользователю, под которым работает приложение АБС или ДБО, доступ с правом SELECT, UPDATE на таблицу fraudwall_alert

    • создать индексы (при необходимости), ускоряющие работу запросов

    11.9.2.2. Индексы по таблице

    Индексы по таблице fraudwall_alert, рекомендуемые к созданию:

    • неуникальный по полю docid

    • неуникальный по полю dboid или absid (в зависимости от того, какое поле создано)

    • неуникальный по полю status

    • неуникальный одновременно по нескольким полям from_account, to_account, amount

    11.9.2.3. Возможность добавления собственных полей

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

    11.9.3. Описание полей таблицы fraudwall_alert

    Внимание

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

    Таблица 26. Перечень полей таблицы fraudwall_alert

    ПолеФорматОписание
    docidтекст, 32 символа

    Уникальный ID документа, формируемый системой FraudWall для служебных целей

    Внимание

    Это поле заполняет только FraudWall. Если документ помещается в таблицу fraudwall_alert системой банка, значение должно быть всегда NULL.

    Внимание

    Это поле не имеет отношения к полю DOCID из VIEW fraudwall_doc. См. также поле dboid таблицы fraudwall_alert

    dboidтекст, 32 символа

    ID документа в системе ДБО, NULL если не известно

    Внимание

    Это поле создается только если анализируемая база данных - база ДБО. Если анализируется база АБС, поле создавать не нужно.

    absidтекст или число

    ID документа в системе АБС, NULL если не известно

    Внимание

    Это поле создается только если анализируемая база данных - база АБС. Если анализируется база ДБО, поле создавать не нужно.

    siteidтекст, 32 символа

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

    Внимание

    Это поле заполняет только FraudWall. Если документ помещается в таблицу fraudwall_alert системой банка, значение должно быть всегда NULL.

    updatedДАТА ВРЕМЯ

    Дата и время создания или обновления записи

    Примечание

    Это поле заполняется как системой FraudWall, так и системами банка

    docnumberтекст, 9 символовПоле документа «Номер документа»
    docdateтекст, 10 символовПоле документа «Дата документа» в формате ДД.ММ.ГГГГ
    from_nameтекст, 4000 символовПоле документа «Наименование плательщика»
    from_innтекст, 12 символовПоле документа «ИНН плательщика»
    from_accountтекст, 20 символовПоле документа «расчетный счет плательщика»
    from_bicтекст, 9 символовПоле документа «БИК банка плательщика»
    from_cityтекст, 1024 символаГород, к которому относится банк плательщика, например, «МОСКВА», «БАРНАУЛ» и т.д.
    from_bankтекст, 4000 символаПоле документа «Наименование банка плательщика»
    to_nameтекст, 4000 символовПоле документа «Наименование получателя»
    to_innтекст, 12 символовПоле документа «ИНН получателя»
    to_accountтекст, 20 символовПоле документа «расчетный счет получателя»
    to_bicтекст, 9 символовПоле документа «БИК банка получателя»
    to_cityтекст, 1024 символаГород, к которому относится банк получателя, например, «МОСКВА», «БАРНАУЛ» и т.д.
    to_bankтекст, 4000 символаПоле документа «Наименование банка получателя»
    purposeтекст, 4000 символаПоле документа «Назначение платежа»
    speedyчислоЗначение 1 соответствует платежу с признаком "срочно", остальные значения (NULL, 0) - обычный платеж
    currencyтекст или число

    3-х буквенный или 3-х числовой код валюты платежа

    Примечание

    Это поле заполняет только анализируемая система.

    amountчисло с 2 знаками после запятой

    Поле документа «Сумма платежа» (в валюте currency)

    Примечание

    При отсутствии или пустом значении поля currency валюта платежа берется из 20-значного счета получателя, а при его отсутствии - из 20-значного счета плательщика

    amountrubчисло с 2 знаками после запятой

    Сумма платежа в рублевом эквиваленте

    balanceчисло

    Сумма доступного остатка на счете плательщика в валюте счета плательщика

    Примечание

    Это поле заполняет только анализируемая система. Если это поле отсутствует, FraudWall получает доступный остаток на счете дополнительным запросом из VIEW fraudwall_balance

    balancerubчисло

    Сумма доступного остатка на счете плательщика в рублевом эквиваленте

    Примечание

    Это поле заполняет только анализируемая система. Если это поле отсутствует, FraudWall получает доступный остаток на счете дополнительным запросом из VIEW fraudwall_balance

    statusтекст, 1 символ

    Статус документа (см. 11.9.1 «Статусы платежа»).

    Внимание

    Если в базе данных Microsoft SQL Server, в которой создана эта таблица, установлен режим поиска без учета регистра, при создании таблицы fraudwall_alert для данного поля нужно явно указать, что регистр учитывается, указав для поля опцию COLLATE Cyrillic_General_CS_AS

    Внимание

    Если документ в таблицу fraudwall_alert помещает АБС или ДБО, значение должно быть всегда X или J.

    showtextтекст, 4000 символов

    Текст - комментарий, который формирует FraudWall для отображения в интерфейсе АБС при открытии данного подозрительного документа

    Примечание

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

    reasonтекст, 4000 символовТекст комментария, который импортируется в FraudWall при получении обновленного статуса из данной таблицы
    from_idтекст или число

    ID клиента - владельца счета плательщика в анализируемой системе или NULL, если не известен

    Примечание

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

    to_idтекст или число

    ID клиента - владельца счета получателя в анализируемой системе или NULL, если не известен

    Примечание

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

    from_operidтекст или число

    ID сотрудника банка в системе АБС, который создал данный платеж (если платеж был создан не клиентом, а сотрудником банка в АБС), NULL в остальных случаях

    Примечание

    Это поле является опциональным (т.е. может отсутствовать) и оно создается только если анализируемая база данных - база АБС

    Примечание

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

    from_operтекст

    Фамилия Имя Отчество сотрудника банка в системе АБС, который создал данный платеж (если платеж был создан не клиентом, а сотрудником банка в АБС), NULL в остальных случаях

    Примечание

    Это поле является опциональным (т.е. может отсутствовать) и оно создается только если анализируемая база данных - база АБС

    Примечание

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

    ipтекст IP адрес компьютера клиента банка в сети Интернет, с которого была работа с документом. Если неизвестно, можно возвращать пустую строку
    deviceтекст

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

    Наименование идентификаторов: mac - MAC-адрес сетевой карты, appid - уникальный ID моб. приложения на моб. устройстве, serial-number - уникальный серийный номер моб. аппарата, imei - IMEI-номер моб. устройства, imsi - IMSI-номер SIM-карты, iccid - уникальный идентификационный номер SIM-карты в международном формате. Если у Вашей системы ДБО есть также свой цифровой отпечаток устройства клиента, необходимо сообщить об этом нам, м.б. выделено уникальное наименование идентификатора.

    Примечание

    Пример такой строки:

    mac="00:11:22:33:44:55" mac="00:11:22:33:44:66" imei="123456789012345"


    11.9.4. Получение платежей для анализа

    Назначение:

    Данный запрос получает перечень платежей, подлежащих анализу системой 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.

    11.9.5. Выгрузка платежа со статусом проверки

    Назначение:

    Данный запрос выгружает в таблицу 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, содержащую указанные поля.

    11.9.6. Обновление статуса платежа в таблице fraudwall_alert на основе ID документа в АБС или ДБО

    Назначение:

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

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

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

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

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

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

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

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

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

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

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

    11.9.7. Обновление статуса платежа в таблице fraudwall_alert на основе ID документа в FraudWall

    Назначение:

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

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

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

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

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

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

    11.9.8. Обновление значения docid платежа в таблице fraudwall_alert

    Назначение:

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

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

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

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

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

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

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

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

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

    Результат выполнения запроса:

    Обновлено значение поля docid в таблице fraudwall_alert для документа с заданными критериями отбора

    11.9.9. Обновление значения showtext платежа в таблице fraudwall_alert

    Назначение:

    Если в таблице fraudwall_alert создано опциональное поле showtext, в него выгружается либо перечень сработавших правил, либо краткий комментарий-инструкция для сотрудника банка.

    Когда выполняется запрос:

    Сразу после проверки платежа или изменения статуса по платежу в интерфейсе FraudWall.

    Входные параметры для запроса:

    showtext = текст

    Если fraudwall_alert содержит dboid (а не absid), то:

    ЕСЛИ dboid=ID документа в ДБО

    Если fraudwall_alert содержит absid (а не dboid), то:

    ЕСЛИ absid=ID документа в АБС

    Результат выполнения запроса:

    Обновлено значение поля showtext в таблице fraudwall_alert для документа с заданными критериями отбора

    11.9.10. Получение списка документов для импорта из fraudwall_alert статуса, выставленного АБС

    Назначение:

    Если в АБС реализована возможность выставления статуса платежу, вызвавшему подозрение, FraudWall может импортировать данный статус.

    Когда выполняется запрос:

    Примерно раз в 5 минут.

    Входные параметры для запроса:

    status = импортируемый статус (одно из значений F, G, R, J)

    Результат выполнения запроса:

    Возвращает значение одно или несколько значений docid (ID документа в FraudWall), соответствующих искомому статусу

    11.9.11. Импорт статуса и комментария из fraudwall_alert, выставленного АБС

    Назначение:

    Если есть документы для импорта статуса (см. 11.9.10 «Получение списка документов для импорта из fraudwall_alert статуса, выставленного АБС» ), FraudWall по каждому документу получает статус и комментарий, выставленный со стороны АБС

    Когда выполняется запрос:

    Для каждого документа, статус которого необходимо импортировать

    Входные параметры для запроса:

    docid = ID документа в FraudWall

    Результат выполнения запроса:

    Возвращает значение status и reason, соответствующих критериям поиска

    11.10. fraudwall_dbolog. Получение журнала событий системы ДБО

    Помимо анализа реквизитов платежей, FraudWall дополнительно анализирует сопутствующую информацию о сессии клиента, в которой был создан данный платеж. При анализе платежа FraudWall автоматически связывает платеж с сессией клиента, тем самым позволяя сопоставить платеж с IP адресом и аппаратными идентификаторами устройства, с которого клиент работал в ДБО.

    Эту информацию FraudWall может получить при анализе дампа трафика либо из базы данных посредством fraudwall_dbolog.

    fraudwall_dbolog по сути представляет собой журнал событий действий клиентов в ДБО и содержит в себе следующую информацию:

    • события успешной/неуспешной аутентификации

    • события смены (сброса) пароля пользователя

    • события завершения сессии

    • и т.д.

    Примечание

    fraudwall_dbolog является опциональной (т.е. может отсутствовать) и создается только в той базе данных, из которой получен платеж для анализа.

    11.10.1. Описание полей структуры fraudwall_dbolog

    Таблица 27. Перечень полей fraudwall_dbolog

    ПолеТип данныхОписание
    time_whenДАТА ВРЕМЯ

    Время события

    from_idтекст или числоИдентификатор клиента в анализируемой системе, которому принадлежит событие, или пустая строка, если это событие не относится к какому-либо клиенту.
    corpidтекст

    Текст логина юридического лица. Если не известен, то можно всегда возвращать пустую строку.

    Примечание

    Понятие «логин юридического лица» применимо только к некоторым системам ДБО, где логин пользователя может быть одинаковым у разных юридических лиц. Например, у юридических лиц с разными логинами «CORP1» и «CORP2» могут быть пользователи с одинаковым логином «DIRECTOR»

    useridтекст

    Текст логина пользователя. Если не известен, то можно всегда возвращать пустую строку.

    ipтекст

    IP адрес компьютера клиента банка в сети Интернет, с которого произошло событие. Если неизвестно, можно возвращать пустую строку

    deviceтекст

    строка, содержащая информацию об идентификаторах устройства клиента, с которого была работа с документом (например, перечень обнаруженных MAC-адресов, IMEI и т.д.). Если неизвестно, можно возвращать пустую строку.

    Наименование идентификаторов: mac - MAC-адрес сетевой карты, appid - уникальный ID моб. приложения на моб. устройстве, serial-number - уникальный серийный номер моб. аппарата, imei - IMEI-номер моб. устройства, imsi - IMSI-номер SIM-карты, iccid - уникальный идентификационный номер SIM-карты в международном формате. Если у Вашей системы ДБО есть также свой цифровой отпечаток устройства клиента, необходимо сообщить об этом нам, м.б. выделено уникальное наименование идентификатора

    Примечание

    Пример такой строки:

    mac="00:11:22:33:44:55" mac="00:11:22:33:44:66" imei="123456789012345"

    sidтекст

    Идентификатор сессии на стороне сервера банка (соответствует полю sid VIEW fraudwall_doc). Если не известен, то можно всегда возвращать пустую строку.

    dbotypeтекст

    Код системы ДБО (присваивается по согласованию с разработчиком FraudWall)

    event_codeтекст

    Краткий код события, который фиксируется системой ДБО (например, "LOGIN", "LOGOUT", "AUTHFAIL", "CREATE_LOGON_OTP", "RESET_PASSWORD", "FORCED_LOGOUT", "CHANGE_PHONE", "DISABLE_NOTICE", "CHANGE_PASSWORD", "ABNORMAL_TRANSITION", "NO_MONEY_DECLINE", "CLOSE_DEPOSIT", "OPEN_CREDIT", "CHANGE_THRESHOLD", "LOCK_USER", "UNLOCK_USER")). Если нет, можно возвращать пустую строку

    event_textтекстДетальный текст события, который может также содержать информацию об идентификаторах устройства клиента, с которого было инициировано данное событие (может содержать User-Agent (с префиксом "user-agent=" или "user-agent:")). Если в event_code фиксируется событие "LOGIN", то при наличии возможности в данном поле лучше фиксировать способ аутентификации: "BIOAUTH" или "PINAUTH"

    11.10.2. Получение новых событий работы клиента

    Назначение:

    Данный запрос получает перечень событий, происходивших в системе ДБО с заданного момента времени

    Когда выполняется запрос:

    Периодически (примерно 1 раз в 1 секунду).

    Входные параметры для запроса:

    time_when >= максимальное время последней записи, полученное в предыдущем запросе

    При первом запуске процесса запрашиваются события, которые произошли не ранее, чем 14 суток от текущего времени. Но в дальнейшем запрашиваются только события, которые происходили за последние 1-2 секунды.

    Примечание

    Если FraudWall получает информацию из анализируемой системы через VIEW fraudwall_dbolog в базе Microsoft SQL Server, в SELECT также добавляется WITH(NOLOCK), исключая тем самым блокировку таблиц анализируемой системы.

    Результат выполнения запроса:

    Возвращает одну или массив структур fraudwall_dbolog, соответствующих запрашиваемым критериям, отсортированный по возрастанию time_when

    11.11. fraudwall_doc. Получение платежей для анализа

    fraudwall_doc используется для получения информации о новых платежах, подлежащих анализу.

    Внимание

    В режиме интеграции в режиме анализа таблицы fraudwall_alert либо по http/https запросу внешней системы, fraudwall_doc не используется.

    Внимание

    fraudwall_doc должна возвращать все платежные документы от клиентов банка, имеющие статусы вида "сохранен черновик", "подписан", "отправлен в АБС" и т.д.

    Результат выполняемого запроса не должен содержать документы с конечным статусом ( "исполнен", "отказан в исполнении", "удален" и т.д.)

    fraudwall_doc по желанию банка может возвращать реквизиты даже платежей, которые еще не отправлены в банк на исполнение (т.е. черновики). Для того, чтобы FraudWall мог отличить черновик документа от его конечной версии (т.е. отправленной в банк на исполнение), предусмотрено поле docid - если оно пустое (NULL или пустая строка), FraudWall будет считать этот документ черновиком. Как только платежное поручение было отправлено в банк на исполнение, у него должно обновится поле updated (чтобы этот документ опять попал в результат выборки), а также docid - оно должно уже содержать непустое значение.

    11.11.1. Описание полей структуры fraudwall_doc

    Таблица 28. Перечень полей fraudwall_doc

    ПолеТип данныхОписание
    updatedДАТА ВРЕМЯВремя последнего изменения состояния документа на стороне сервера банка

    Примечание

    При создании VIEW убедитесь, что поле в базе данных соответствует времени на стороне сервера, а не времени на стороне клиента (особенно это актуально для толстого клиента ДБО)

    docidтекст или числоИдентификатор документа в анализируемой системе, или пустое значение, если документ еще не отправлен в банк на исполнение (например, является черновиком или еще не подписан клиентом)
    sidтекст или число

    Идентификатор сессии на стороне сервера ДБО банка. Если не известен, то можно всегда возвращать пустое значение.

    Примечание

    Идентификатор сессии применим только для тонкого клиента - это значение, передаваемое браузером на сервер банка в виде JSESSIONID=12345678, SID=12345678, ASPSESSIONID=12345678. Если система ДБО не сохраняет в базе значение SID, всегда возвращайте пустое значение. Для "толстого" клиента ДБО возвращайте всегда пустое значение, т.к. в "толстом" клиенте сессия отсутствует.

    ipтекст IP адрес компьютера клиента банка в сети Интернет, с которого была работа с документом. Если неизвестно, можно возвращать пустую строку
    deviceтекст

    строка, содержащая информацию об идентификаторах устройства клиента, с которого была работа с документом (например, перечень обнаруженных MAC-адресов, IMEI и т.д.). Если неизвестно, можно возвращать пустую строку.

    Наименование идентификаторов: mac - MAC-адрес сетевой карты, appid - уникальный ID моб. приложения на моб. устройстве, serial-number - уникальный серийный номер моб. аппарата, imei - IMEI-номер моб. устройства, imsi - IMSI-номер SIM-карты, iccid - уникальный идентификационный номер SIM-карты в международном формате. Если у Вашей системы ДБО есть также свой цифровой отпечаток устройства клиента, необходимо сообщить об этом нам, м.б. выделено уникальное наименование идентификатора

    Примечание

    Пример такой строки:

    mac="00:11:22:33:44:55" mac="00:11:22:33:44:66" imei="123456789012345"

    useridтекст Логин, который вводил клиент для входа в ДБО. Если неизвестно, можно возвращать пустую строку
    docnumberтекст или число Поле документа «Номер документа».
    docdateДАТА ВРЕМЯ Поле документа «Дата документа».

    Внимание

    Обратите внимание, что тип данных этого поля - ДАТА ВРЕМЯ

    from_operidтекст или число

    ID сотрудника банка в системе АБС, который создал данный платеж (если платеж был создан не клиентом, а сотрудником банка в АБС), NULL в остальных случаях

    Примечание

    Если анализируемая система - ДБО, создавать это поле нельзя.

    Если анализируемая система - АБС, создавать это поле нужно всегда, даже если оно всегда будет возвращать NULL

    from_operтекст

    Фамилия Имя Отчество сотрудника банка в системе АБС, который создал данный платеж (если платеж был создан не клиентом, а сотрудником банка в АБС), NULL в остальных случаях

    Примечание

    Если анализируемая система - ДБО, создавать это поле нельзя.

    Если анализируемая система - АБС, создавать это поле нужно всегда, даже если оно всегда будет возвращать NULL

    from_idтекст или число

    ID клиента - владельца счета плательщика в анализируемой системе или NULL, если не известен

    Примечание

    Размерность и тип поля выбираются исходя из соответствующих типов полей в базе АБС или ДБО, т.к. FraudWall обрабатывает это поле как текст неограниченной длины.

    from_nameтекстПоле документа «Наименование плательщика»
    from_innтекстПоле документа «ИНН плательщика»
    from_accountтекстПоле документа «расчетный счет плательщика»
    from_bicтекстПоле документа «БИК банка плательщика»
    from_bankтекст

    Наименование банка, соответствующего БИК банка плательщика

    Примечание

    Можно всегда возвращать NULL - в этом случае значение будет браться из встроенного справочника банков РФ

    from_cityтекст

    Город, соответствующий банку плательщика

    Примечание

    Можно всегда возвращать NULL - в этом случае значение будет браться из встроенного справочника банков РФ

    to_idтекст или число

    Идентификатор клиента в анализируемой системе, которому принадлежит расчетный счет получателя

    Примечание

    Если такой информации нет, или же расчетный счет получателя открыт в другом банке, можно возвращать NULL

    to_nameтекстПоле документа «Наименование получателя»
    to_innтекстПоле документа «ИНН получателя»
    to_accountтекстПоле документа «расчетный счет получателя»
    to_bicтекстПоле документа «БИК банка получателя»
    to_bankтекст

    Наименование банка, соответствующего БИК банка получателя

    Примечание

    Можно всегда возвращать NULL - в этом случае значение будет браться из встроенного справочника банков РФ

    to_cityтекст

    Город, соответствующий банку получателя

    Примечание

    Можно всегда возвращать NULL - в этом случае значение будет браться из встроенного справочника банков РФ

    currencyтекст или число

    3-х буквенный или 3-х числовой код валюты платежа

    amountчисло с 2 знаками после запятой

    Поле документа «Сумма платежа» (в валюте currency)

    Примечание

    При отсутствии или пустом значении поля currency валюта платежа берется из 20-значного счета получателя, а при его отсутствии - из 20-значного счета плательщика

    purposeтекстПоле документа «Назначение платежа»
    speedyчислоЗначение 1 соответствует платежу с признаком "срочно", остальные значения (NULL, 0) - обычный платеж
    to_paygate_dboidтекстИдентификатор поставщика услуг в ДБО (цифровой идентификатор уникальной связки "поставщик услуги -тип услуги" (например, идентификаторы для услуг Ростелеком-интернет, Ростелеком-телевидение и т.д.)) - опционально, значение может быть пустым
    to_paygate_accountтекстИдентификатор лицевого счета, номер кошелька, но мер телефона или иной идентификатор клиента в системе поставщика услуг - опционально, значение может быть пустым

    11.11.2. Получение платежей для проверки из VIEW fraudwall_doc

    Назначение:

    Данный запрос выполняется только в режиме анализа платежей из VIEW fraudwall_doc.

    Когда выполняется запрос:

    Период опроса указывается в свойствах сайта в параметре "Периодичность поиска платежей в базе данных" и составляет обычно раз в 5-30 секунд.

    Входные параметры для запроса:

    updated >= максимальное время updated, полученное в предыдущем запросе

    Если в свойствах сайта в параметре Анализировать платежи, у которых поле "дата платежа" отлично от "любое", в запросе дополнительно указывается:

    И docdate >= текущие сутки минус число рабочих дней, указанных в параметре "Анализировать платежи, у которых поле "дата платежа"..."

    Примечание

    Если FraudWall получает информацию из анализируемой системы через VIEW fraudwall_doc в базе Microsoft SQL Server, в SELECT также добавляется WITH(NOLOCK), исключая тем самым блокировку таблиц анализируемой системы.

    Результат выполнения запроса:

    Возвращает массив структур fraudwall_doc платежей, не исполненных и не отказанных в АБС, возможно даже не отправленных в банк на исполнение (см. поле docid), удовлетворяющий заданным критериям.

    11.12. fraudwall_alert_client. Получение и выгрузка подозрительных клиентов банка

    fraudwall_alert_client используется для получения информации о клиентах, по которым в банке были применены ограничения, а также для выгрузки такой информации из системы FraudWall в системы банка.

    Внимание

    Хранимые процедуры fraudwall_client_blockdbo и fraudwall_client_enabledbo, таблица (VIEW) fraudwall_alert_client могут быть реализованы специалистами Банка самостоятельно, либо с привлечением разработчиков системы дистанционного банковского обслуживания. В данном разделе документации описаны варианты взаимодействия, которые поддерживает FraudWall со своей стороны, в части блокировки/разблокирования доступа клиенту к ДБО.

    11.12.1. Описание полей структуры fraudwall_alert_client

    Таблица 29. Перечень полей fraudwall_alert_client

    ПолеТип данныхОписание
    idтекст или числоИдентификатор клиента в анализируемой системе
    updatedДАТА ВРЕМЯВремя последнего изменения статуса клиента, может быть NULL
    blockdboчисло 0 или 10 - ограничений на работу в ДБО у клиента нет, 1 - клиенту запрещено работать в ДБО

    Примечание

    Под запретом работы в ДБО подразумевается организационные ограничения, вызванные требованиями сотрудников фин.мониторинга или служб безопасности запретить работу клиента в ДБО.

    Внимание

    Если у клиента заблокирована учетная запись в ДБО из-за срабатывания систем защиты (например блокировка из-за некорректного ввода пароля), это не считается запретом в работе ДБО и соответствует значению 0.

    reasonтекстКомментарий по изменению статуса клиента, может быть пустой строкой

    11.12.2. Импорт списка клиентов, которым запрещена работа в ДБО

    Назначение:

    Т.к. статус блокировки клиенту ДБО может быть выставлен непосредственно в системе ДБО, в FraudWall предусмотрен механизм периодического импорта перечня таких клиентов.

    Когда выполняется запрос:

    Примерно 1 раз в 30 минут.

    Входные параметры для запроса:

    blockdbo = 1

    Результат выполнения запроса:

    Возвращает массив структур fraudwall_alert_client, относящихся к клиентам, которым запрещено работать в ДБО.

    11.12.3. Получение актуального статуса клиента

    Назначение:

    При открытии в интерфейсе FraudWall платежа либо досье клиента, FraudWall запрашивает из всех систем ДБО актуальный статус по клиенту и отображает ее в интерфейсе FraudWall

    Когда выполняется запрос:

    В момент открытия в интерфейсе FraudWall платежа или досье клиента.

    Входные параметры для запроса:

    id = ID клиента

    Результат выполнения запроса:

    Возвращает структуру fraudwall_alert_client, соответствующую клиенту с заданным ID в ДБО.

    11.12.4. Блокирование клиенту работы в ДБО

    Назначение:

    При выставлении в интерфейсе системы FraudWall статуса "клиенту должна быть запрещена работа в ДБО", эта информация должна быть выгружена в систему ДБО, после чего в ДБО клиент должен быть заблокирован.

    Когда выполняется запрос:

    Сразу после выставления статуса в интерфейсе FraudWall.

    Входные параметры для запроса:

    Существует 3 варианта выгрузки статуса из FraudWall в ДБО. FraudWall последовательно пытается выполнить все данные варианты выгрузки статуса - из них должен отработать только один.

    Вариант 1. FraudWall вызывает хранимую процедуру fraudwall_client_blockdbo, аргументом которой является ID клиента

    Внимание

    Чтобы остальные варианты не отрабатывали, на fraudwall_alert_client должен быть предоставлен доступ только на чтение (SELECT).

    Вариант 2. Если fraudwall_alert_client представляет собой таблицу, FraudWall пытается добавить (INSERT) в нее новую запись, содержащую ID клиента, значение blockdbo, равное 1, а также updated в текущее время.

    Внимание

    Право на INSERT для таблицы fraudwall_alert_client необходимо предоставлять только если предполагается работа по данному варианту.

    По таблице fraudwall_alert_client обязательно должен быть уникальный индекс по полю id, исключающий появление в таблице нескольких записей с одним и тем же id.

    Если добавление (INSERT) новой записи приведет к появлению двух записей с одним и тем же id, этот запрос будет неуспешным, и FraudWall обновит статус посредством UPDATE по варианту 3.

    Вариант 3. Если fraudwall_alert_client представляет собой таблицу или VIEW со списком статусов всех клиентов, FraudWall пытается обновить (UPDATE) для записи с заданным ID клиента значение blockdbo в значение 1, а также updated в текущее время .

    Результат выполнения запроса:

    После выполнения данного запроса, система ДБО должна заблокировать возможность работы клиента в ДБО.

    11.12.5. Разблокирование клиенту работы в ДБО

    Назначение:

    При выставлении в интерфейсе системы FraudWall статуса "клиенту должна быть разрешена работа в ДБО", эта информация должна быть выгружена в систему ДБО, после чего клиент должен иметь возможность работать в в ДБО.

    Когда выполняется запрос:

    Сразу после выставления статуса в интерфейсе FraudWall.

    Входные параметры для запроса:

    Существует 2 варианта выгрузки статуса из FraudWall в ДБО. FraudWall последовательно пытается выполнить все данные варианты выгрузки статуса - из них должен отработать только один.

    Вариант 1. FraudWall вызывает хранимую процедуру fraudwall_client_enabledbo, аргументом которой является ID клиента

    Внимание

    Чтобы остальные варианты не отрабатывали, на fraudwall_alert_client должен быть предоставлен доступ только на чтение (SELECT).

    Вариант 2. FraudWall пытается обновить (UPDATE) для записи с заданным ID клиента значение blockdbo в значение 0, а updated в текущее время.

    Результат выполнения запроса:

    После выполнения данного запроса, система ДБО должна разблокировать возможность работы клиента в ДБО.

    12. Приложения

    12.1. Процедура регистрации операционной системы RedHat Enterprise Linux

    Примечание

    При установке системы FraudWall на операционную систему CentOS, указанные в этом разделе действия выполнять не требуется.

    Выполняем команду регистрации сервера в RedHat Customer Portal : subscription-manager register --auto-attach

    Если подключение к сети Internet осуществляется в проксированном режиме, в командной строке необходимо дополнительно указать IP адрес proxy-сервера:subscription-manager register --auto-attach --proxy=1.2.3.4:3128

    Если в процессе установки были ошибки, проверяем настройки сети, а также наличия на межсетевом экране и прокси-сервера необходимых прав доступа к сети Интернет.

    Убеждаемся, что сервер имеет статус "Действительный" при выполнении команды:subscription-manager status

    Рисунок 84. Статус успешной регистрации сервера в RedHat Customer Portal

    Статус успешной регистрации сервера в RedHat Customer Portal

    Внимание

    Если текущий статус неуспешный, зайдите на сайт redhat.com в раздел Red Hat Customer Portal и устраните проблемы.

    После успешной регистрации в RedHat Customer Portal, необходимо подключить дополнительные репозитории командами:

    subscription-manager repos --enable=rhel-6-server-rpms

    subscription-manager repos --enable=rhel-6-server-optional-rpms

    Убеждаемся, что серверу подключены 2 этих дополнительных репозитория командой:subscription-manager repos --list-enabled

    Рисунок 85. Репозитории, которые должны быть подключены серверу

    Репозитории, которые должны быть подключены серверу


    Внимание

    В случае установки компонентов системы FraudWall на нескольких серверах, в Red Hat Customer Portal должны быть зарегистрированы все сервера

    Без успешной регистрации сервера в Red Hat Customer Portal дальнейшая установка системы FraudWall невозможна

    12.2. Процедура экспорта SSL-сертификата из IIS

    Установка на сервер FraudWall такого же SSL-сертификата, который установлен на существующем WWW-сервере ДБО, позволит обеспечить плавный и незаметный переход клиентов на работу через сервер FraudWall.

    Внимание

    Экспорт сертификата осуществляется непосредственно с существующего WWW-сервера ДБО. Для этого Вам необходимо удаленно подключится к рабочему столу сервера, например, с помощью TeamViewer, RADMIN, DameWare или Microsoft Terminal Client.

    Пример процедуры экспорта SSL-сертификата в операционной системе Microsoft Windows (например, используемый WWW-сервером IIS):

    1. На WWW-сервере системы ДБО через меню «Пуск\Выполнить» запускаем команду: mmc

    2. Выбрать в меню «Консоль» пункт «Добавить оснастку»:

      Рисунок 86. Пункт меню mmc для добавления оснастки

      Пункт меню mmc для добавления оснастки

    3. Нажимаем на кнопку «Добавить» и добавляем оснастку «Сертификаты»:

      Рисунок 87. Добавление оснастки Сертификаты

      Добавление оснастки Сертификаты

    4. На открывшемся диалоге выбираем «управление сертификатами учетной записью службы», затем «локальный компьютер»:

      Рисунок 88. Управление сертификатами учетной записью службы

      Управление сертификатами учетной записью службы

    5. В списке доступных служб выбираем «Службу веб-публикаций»:

      Рисунок 89. Выбор службы веб-публикаций

      Выбор службы веб-публикаций

    6. Выполняем аналогичные действия для «управления сертификатами учетной записи компьютера»:

      Рисунок 90. Управление сертификатами учетной записью компьютера

      Управление сертификатами учетной записью компьютера

    7. Параллельно открываем свойства существующего сайта ДБО в консоли администрирования IIS и открываем на просмотр сертификат, используемый для существующего сайта ДБО

    8. В ранее открытой консоли mmc ищем в ветке Личные (Personal) сертификатов службы либо компьютера сертификат, используемый WWW-сервером системы ДБО (как правило, достаточно сверить идентичность серийного номера и даты устаревания сертификата):

      Рисунок 91. Выбор сертификата

      Выбор сертификата

    9. Правой кнопкой мыши выбираем меню экспорта сертификата:

      Рисунок 92. Выбор меню экспорта сертификата

      Выбор меню экспорта сертификата

    10. Экспортируем сертификат, при этом обязательно указываем опцию «экспортировать секретный ключ» («Export private key»), формат «PKCS#12», включаем «При возможности включить дерево сертификатов» («Include all certificates in the certification path if possible»), выключаем опции «Включить усиленную защиту» («Enable strong protection») и «Удалить секретный ключ после экспорта» («Delete the private key if export is successful»), как показано на рисунке:

      Рисунок 93. Опции экспорта сертификата

      Опции экспорта сертификата

    11. Указываем пароль, на котором будет зашифрован секретный ключ сертификата

      Внимание

      В качестве символов пароля рекомендуется указывать только латинские буквы разного регистра и цифры.

      Не забывайте пароль экспорта, так как он понадобится при конфигурировании системы FraudWall

      Файл экспорта содержит критичную информацию о секретном ключе сайта ДБО. Рекомендуется удалить экспортный файл после конфигурирования системы FraudWall

    12.3. Формирование bsi.xml в формате Linux

    1. Заходим консолью на Web-сервер BS-Client

    2. Создаем архивную копию конфигурационного файла модуля BSI bsi.xml (как правило, он располагается в папке C:\BSSystems\Inetpub\Bsi_scripts\RT_Ic\) (это требуется для того, чтобы в дальнейшем восстановить его содержимое)

    3. Запускаем bsiset.exe (как правило, он располагается в папке C:\BSSystems\Inetpub\EXE\)

    4. Переходим в окно выбора конфигурационного файла (кнопка с «…»):

      Рисунок 94. Выбор конфигурационного файла утилиты bsiset.exe

      Выбор конфигурационного файла утилиты bsiset.exe

    5. Выбираем в "Files of type" тип "Config file (*.xml)" и открываем конфигурационный файл bsi.xml (как правило, он располагается в папке C:\BSSystems\Inetpub\Bsi_scripts\RT_Ic\):

      Рисунок 95. Выбор конфигурационного файла bsi.xml в утилите bsiset.exe

      Выбор конфигурационного файла bsi.xml в утилите bsiset.exe

    6. Нажимаем на кнопку Edit утилиты bsiset.exe

    7. Убираем галочку для опции Indent XML в нижней части интерфейса утилиты bsiset.exe:

      Рисунок 96. Опция bsiset.exe, которая устанавливает формат bsi.xml

      Опция bsiset.exe, которая устанавливает формат bsi.xml

    8. Как правило, в рабочей системе конфигурационный файл bsi.xml уже содержит все необходимые конфигурационные параметры, поэтому их редактирование не обязательно (за исключением путей к trace- и log- файлам). Если необходимо формирование trace- либо log-файлов модуля BSI, необходимо выставить корректные пути к файлу в формате Linux:

      Рисунок 97. Путь к trace-файлу в формате Linux

      Путь к trace-файлу в формате Linux

      Внимание

      Обязательно проверьте, что во всех параметрах, отображаемых в интерфейсе bsiset.exe, отсутствуют пути к файлам в формате Windows (типа C:\BSSystems\). Модуль BSI на сервере FraudWall работает под операционной системой Red Hat Enterprise Linux, формат путей к файлам отличается (/var/log/). Если формат файлов не будет исправлен, модуль BSI работать не будет и в файлах в директории /var/log/tomcat6 будет зафиксирована соответствующая ошибка.

      Примечание

      Подробности конфигурирования bsi.xml для модуля BSI под Apache находятся в документации к системе BS-Client

    9. Закрываем все окна утилиты bsiset.exe, нажав на кнопку Ok, а также выходим из нее, нажав на кнопку Exit.

    10. Через Проводник Windows в сетевой диск bsi (или в файловом менеджере в директорию /etc/tomcat6/RT_Ic по протоколу SFTP/SCP) копируем обновленный файл конфигурации bsi.xml (как правило, он располагается в папке C:\BSSystems\Inetpub\Bsi_scripts\RT_Ic\).

    11. На Web-сервере BS-Client восстанавливаем файл bsi.xml из архивной копии, созданной на предыдущих этапах.

    12.4. Установка ODBC-драйверов

    Установка драйверов ODBC осуществляется в следующей последовательности:

    1. Примечание

      На один и тот же сервер FraudWall при необходимости может быть установлено несколько различных ODBC-драйверов, например, для СУБД Oracle и Microsoft SQL Server.

    12.4.1. Установка ODBC-драйверов для Oracle

    ODBC-драйвера к Oracle являются частью программного обеспечения Oracle Instant Client, которое можно скачать с сайта Oracle (меню Download, пункт Instant Client). Необходимо выбрать «Instant Client for Linux x86», затем скачать следующие файлы относящиеся к версии 11.2 или 12.x:

    • oracle-instantclient11.2-basic-11.2.0.3.0-1.i386.rpm

    • oracle-instantclient11.2-odbc-11.2.0.3.0-1.i386.rpm

    Скаченные файлы необходимо записать на сервер FraudWall (если используется несколько серверов, настройки выполняются на тех серверах, где требуются ODBC-драйвера), затем выполнить в консоли последовательно команды:

    • rpm -i oracle-instantclient11.2-basic-11.2.0.3.0-1.i386.rpm

    • rpm -i oracle-instantclient11.2-odbc-11.2.0.3.0-1.i386.rpm

    • yum install fraudwall-odbc-oracle

    Примечание

    FraudWall автоматически определяет, какие версии драйверов Oracle были установлены, и использует самую максимальную версию. Деинсталлировать старые версии драйверов при этом не нужно.

    После установки, в директории /usr/lib/oracle/NNN/client/network/admin/ (NNN соответствует самой большой установленной версии драйверов Oracle) необходимо в файлах tnsnames.ora и sqlnet.ora прописать параметры для подключения к базе данных (их можно уточнить у администраторов базы данных Oracle).

    Внимание

    После выполнения настроек необходимо закрыть текущую SSH-сессию и переподключиться к серверу FraudWall повторно (если не уверены, просто перегрузите сервер командой reboot). Если этого не сделать, переменные окружения не обновятся, и в дальнейшем при установке будут ошибки.

    12.4.2. Установка ODBC-драйверов для Microsoft SQL Server и Sybase

    В качестве ODBC-драйверов к СУБД Microsoft SQL Server и Sybase используются бесплатно распространяемые драйвера проекта FreeTDS.

    Для начала установки ODBC-драйверов на сервер FraudWall необходимо выполнить команду: yum install fraudwall-odbc-freetds

    12.4.3. Установка ODBC-драйверов для PostgreSQL

    Примечание

    Несмотря на то, что FraudWall для работы с собственной базой данных использует нативные протоколы обмена с базой данных PostgreSQL, при работе с внешними базами данных (систем ДБО и АБС) используется протокол ODBC, даже если эта база данных работает на СУБД PostgreSQL.

    ODBC-драйвера к PostgreSQL входят в комплект программного обеспечения, поставляемого совместно с операционной системой.

    Для установки ODBC-драйверов для базы данных PostgreSQL необходимо выполнить команду: yum install fraudwall-odbc-psql

    12.4.4. Установка ODBC-драйверов для Firebird

    Для установки ODBC-драйверов для базы данных Firebird необходимо выполнить команду: yum install fraudwall-odbc-firebird

    12.4.5. Установка ODBC-драйверов для Progress OpenEdge

    Начиная с версии 10.0, в комплект СУБД Progress OpenEdge входят бесплатные ODBC-драйвера под названием SQL Client Access. Для установки понадобятся:

    • SQL Client Access версии 11.6 linux 32-bit

    • Progress OpenEdge 11.6.4.0 Service Pack 4

    Перед началом установки ODBC-драйвера необходимо выполнить команду: yum install fraudwall-odbc-progress

    Внимание

    Необходимо закрыть текущую SSH-сессию и переподключиться к серверу FraudWall повторно (если не уверены, просто перегрузите сервер командой reboot). Если этого не сделать, переменные окружения не обновятся, и в дальнейшем при установке будут ошибки.

    Затем необходимо открыть файл /usr/lib/progress/silent.cfg на редактирование и указать в нем данные, соответствующие бесплатной лицензии на ODBC-драйвер:

    • в параметре name указывается наименование организации

    • в параметре serial указывается значение Serial Number бесплатного драйвера

    • в параметре control указывается Control Number бесплатного драйвера

    Создайте временную папку для установки SQL Client Access командой:

    mkdir /var/tmp/pgoe

    Скопируйте в /var/tmp/pgoe архив SQL Client Access (имя файла PROGRESS_OE_11.6_LNX_32_SQLCLIENTACCESS.tar.gz), перейдите в эту директорию, и в ней выполните команду:

    tar xvf PROGRESS_OE_11.6_LNX_32_SQLCLIENTACCESS.tar.gz

    Создайте временную папку для установки SP 4 командой:

    mkdir /var/tmp/pgoe4

    Скопируйте в /var/tmp/pgoe4 архив SP4 (имя файла PROGRESS_OE_11.6.4_LNX_32.tar.gz), перейдите в эту директорию, и в ней выполните команду:

    tar xvf PROGRESS_OE_11.6.4_LNX_32.tar.gz

    Перейдите в директорию /tmp

    Установите SQL Client Access командой:

    TERM=linux /var/tmp/pgoe/proinst -b /usr/lib/progress/silent.cfg

    Установите SP4 командой (обратите внимание, папка pgoe4 !):

    TERM=linux /var/tmp/pgoe4/proinst -b /usr/lib/progress/sp4.ini

    Перейдите в директорию /usr/lib/progress/odbc/lib и посмотрите точное название файла pgoeNNN.so (значение NNN зависит от версии ODBC-драйверов).

    Далее необходимо открыть на редактирование файл /etc/odbcinst.ini, и в секции [Progress OpenEdge] исправить значение параметра Driver, указав правильный путь к файлу pgoeNNN.so

    Для проверки корректности установки драйверов выполните команду (укажите корректное значение NNN)

    ivtestlib /usr/lib/progress/odbc/lib/pgoeNNN.so

    В результате выполнения команды не должно отобразиться каких-либо сообщений об ошибке.

    12.4.6. Установка ODBC-драйверов для Pervasive SQL

    ODBC-драйвера к СУБД Pervasive SQL распространяются разработчиком данной СУБД.

    Перед началом установки ODBC-драйверов к СУБД Pervasive SQL необходимо с сайта компании-разработчика данной СУБД скачать архив PSQL Client - Linux TAR 32-bit для версии v11 (SP3 и выше).

    Данный TAR-файл необходимо записать на сервер Fraudwall в директорию /tmp, затем выполнить команду: yum install fraudwall-odbc-pervasive

    Внимание

    После выполнения настроек необходимо закрыть текущую SSH-сессию и переподключиться к серверу FraudWall повторно (если не уверены, просто перегрузите сервер командой reboot). Если этого не сделать, переменные окружения не обновятся, и в дальнейшем при установке будут ошибки.

    12.4.7. Установка ODBC-драйверов для H2

    Взаимодействие с базой данных H2 осуществляется посредством протокола Postgresql.

    Для установки ODBC-драйверов для базы данных H2 необходимо выполнить команду: yum install fraudwall-odbc-h2

    12.4.8. Установка ODBC-драйверов для MySQL

    ODBC-драйвера к MySQL входят в комплект программного обеспечения, поставляемого совместно с операционной системой.

    Для установки ODBC-драйверов для базы данных MySQL необходимо выполнить команду: yum install fraudwall-odbc-mysql

    Далее необходимо открыть на редактирование файл /etc/odbcinst.ini, и в секции [MySQL] исправить значение параметра Driver, указав правильный путь к файлу libmyodbc3.so (для MySQL до версии 4.1.1) либо libmyodbc5.so (для MySQL версии 4.1.1 и выше)

    12.4.9. Редактирование конфигурационного файла /etc/odbc.ini

    Начиная с версии 4.3.4, редактирование файла /etc/odbc.ini необходимо осуществлять через вкладку "Базы данных" интерфейса "Система\Конфигурирование".

    12.4.10. Диагностика и решение проблем с ODBC-драйверами

    Проверить корректность подключения к внешней базе данных можно, выполнив следующую команду (вместо dsn, user и password необходимо соответственно указать присвоенное ODBC DSN - имя (отображатся во вкладке "Базы данных" интерфейса "Система\Конфигурирование"), а также логин и пароль пользователя, созданного в базе данных): isql -v dsn "user" "password"

    При корректных настройках будет осуществлено подключение к базе данных и можно будет выполнить SQL-команды. Для выхода из утилиты isql необходимо нажать Ctrl+C, либо ввести команду quit

    Для включения диагностического trace-файла необходимо открыть на редактирование файл /etc/odbcinst.ini и в секции [ODBC] раскомментировать (т.е. удалить символ ‘#’ в начале) параметр TraceFile:

    [ODBC]
    # Для формирования отладочного trace-файла раскомментируйте
    # параметры TraceFile, Trace и ForceTrace
    TraceFile       = /var/log/fraudwall/odbc.log
    Trace           = Yes
    ForceTrace      = Yes
    

    После сохранения изменений, необходимо выполнить команды service fw_control restart

    service fw_master restart

    Внимание

    Не забудьте отключить формирование trace-файла после устранения ошибок, закомментировав указанные параметры TraceFile, Trace и ForceTrace и перестартовав сервисы fw_control и fw_master, как указано выше.

    Если вы самостоятельно не смогли устранить проблему, необходимо обратиться в службу технической поддержки.

    Термины и определения

    GMT

    Greenwich Mean Time, Среднее время по Гринвичу - устаревший стандарт отсчета мирового времени. В настоящее время вместо GMT используют UTC

    UTC

    Universal Coordinated Time, Всемирное координированное время - стандарт, по которому общество регулирует часы и время. Отличается от GMT на доли секунды.

    АБС

    автоматизированная банковская система

    ДБО

    дистанционное банковское обслуживание

    Сайт

    WWW-сайт, защищаемый системой FraudWall. Например, это WWW-сайт системы ДБО, WWW-сайт банка и т.д.

    фрод

    (англ. fraud - обман, мошенничество, подделка) термин, означающий действия злоумышленника, направленные на получение незаконной прибыли за счет кражи финансовых средств у клиентов банка

    антифрод - система

    специализированный комплекс программно - аппаратных средств, направленных на предотвращение фрода