UTM5 RFW

12    

Схема работы UTM5 RFW#

Аффектор UTM5 RFW является демоном исполнения команд, поступающих от ядра UTM5. RFW предназначен для управления сторонним ПО, включая брандмауэры, маршрутизаторы, шейперы и т.д.

Краткое описание схемы работы:

1.Соединение с ядром UTM5;

2.Получение команд от ядра UTM5;

3.Выполнение команд локально или удаленно.

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

UTM5 RFW устанавливает постоянное соединение с ядром UTM5 по протоколу Stream, ожидая команд, генерируемых ядром при наступлении определенных событий. Соотнесение событий и исполняемых команд производится в интерфейсе администратора на странице Настройки: Правила firewall.

Команды исполняются локально на том же сервере, где запущен RFW, если в качестве типа брандмауэра выбрано Local, и удаленно по rsh – если в качестве типа брандмауэра выбрано Cisco (rsh).

Если RFW не подключён к ядру, команды кэшируются в течение 24 часов. При переподключении RFW к ядру может происходить выполнение некоторых команд согласно заданным флагам синхронизации (см. Синхронизация правил); при подключении без указания флагов все кэшированные правила будут отправлены на аффектор. Кроме того при запуске RFW или при его переподключении к ядру может исполняться произвольная команда, заданная параметром firewall_flush_cmd (см. Конфигурационный файл).

Правила firewall#

Правило firewall – это объект, задающий шаблон выполняемой команды и определяющий условия её выполнения.

Перечень зарегистрированных в системе правил firewall находится на вкладке Настройки: Правила firewall интерфейса администратора.

Готовые для выполнения правила передаются на выполнение UTM5 RFW.

Правила firewall обладают следующими группами параметров:

–Областью применимости (для каких пользователей правило выполняется);

–Инициирующим событием (причина выполнения правила);

–Местом выполнения (RFW, которому передается правило, и соответствующий ему брандмауэр, на котором правило выполняется);

–Шаблоном (собственно команда).

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

–Область применимости

свойство, определяющее лицевые счета, к которым применимо данное правило. Если выбрана опция Все пользователи, под действие правила подпадают все лицевые счета, зарегистрированные в системе. В противном случае для выбора подмножества лицевых счетов можно использовать следующие условия: выбор по идентификатору пользователя, выбор по принадлежности пользователя к группе и выбор по тарифному плану. По умолчанию правило применяется к лицевым счетам, удовлетворяющим любому из заданных условий, если их более одного (т. е. учитывается объединение условий – логическое ИЛИ). При выборе альтернативной опции учитывается пересечение условий (логическое И), т. е. правило применяется к лицевым счетам, удовлетворяющим всем условиям.

–Инициирующее событие (одно или более)

выбирается из списка (см. События).

–Место выполнения правила

свойство, задающее конкретный брандмауэр путём выбора из списка, или (если выбрана соответствующая опция) все брандмауэры.

–Шаблон команды

строка, которая может содержать переменные (см. Переменные), заменяемые соответствующими значениями непосредственно при отправке команды на RFW.

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

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

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

Создание правил описано в примере Создание правила firewall.

Переменные#

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

Список событий приведён ниже (см. События).

Среди переменных используются следующие перечисления:

–Типы блокировки

см. Лицевые счета.

–Типы услуг

см. Услуги.

События#

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

–Включение Интернета

выполняется для каждой IP-группы в каждой сервисной связке услуги передачи IP-трафика, принадлежащего лицевому счёту, при изменении статуса Internet данного счёта с "выключен" на "включен";

–Выключение Интернета

выполняется дважды для каждой IP-группы в каждой сервисной связке услуги передачи IP-трафика, принадлежащего лицевому счёту, при изменении статуса Internet данного счёта с "включен" на "выключен";

–Добавление пользователя

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

–Изменение пользователя

выполняется для пользователя при изменении данных этого пользователя;

–Удаление пользователя

выполняется для пользователя при его удалении;

–Изменение состояния блокировки

выполняется для лицевого счёта при изменении состояния блокировки (т. е. при его блокировке или разблокировке);

–Оповещение об изменении баланса

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

–Открытие сессии

выполняется для сервисной связки при поступлении RADIUS-запроса Accounting-Start;

–Закрытие сессии

выполняется для сервисной связки при поступлении RADIUS-запроса Accounting-Stop;

–Добавление связки dialup

выполняется для сервисной связки услуги коммутируемого доступа при её создании;

–Изменение связки dialup

выполняется для сервисной связки услуги коммутируемого доступа при изменении её параметров;

–Удаление связки dialup

выполняется для сервисной связки услуги коммутируемого доступа при её удалении;

–Добавление связки IP-трафика

выполняется для сервисной связки услуги передачи IP-трафика при её добавлении;

–Изменение связки IP-трафика

выполняется для сервисной связки услуги передачи IP-трафика при изменении её параметров;

–Удаление связки IP-трафика

выполняется для сервисной связки услуги передачи IP-трафика при её удалении;

–Добавление связки телефонии

выполняется для сервисной связки услуги телефонии при её добавлении;

–Изменение связки телефонии

выполняется для сервисной связки услуги телефонии при изменении её параметров;

–Удаление связки телефонии

выполняется для сервисной связки услуги телефонии при её удалении;

–Включение hotspot

выполняется для сервисной связки hotspot при авторизации пользователя;

–Выключение hotspot

выполняется для сервисной связки hotspot при выходе пользователя или прекращении сессии;

–Регистрация абонента hotspot

выполняется для пользователя при добавлении данного пользователя в систему через web-интерфейс;

–Добавление тех. параметра

выполняется для сервисной связки при добавлении к ней технического параметра (см. Технические параметры);

–Изменение тех. параметра

выполняется для сервисной связки при изменении связанного с ней технического параметра;

–Удаление тех. параметра

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

–Установка ширины входящего канала

выполняется для каждой IP-группы при наступлении условий шейпирования для входящего канала по данной сервисной связке (см. Динамическое шейпирование);

–Изменение ширины входящего канала

выполняется для каждой IP-группы при смене условий шейпирования для входящего канала по данной сервисной связке (например, при переходе трафика через границы шейпирования);

–Снятие ограничений на входящий канал

выполняется для каждой IP-группы при выходе входящего канала по данной сервисной связке из-под условий шейпирования (например, при обнулении количества трафика в момент завершения отчётного периода);

–Установка ширины исходящего канала

выполняется для каждой IP-группы при наступлении условий шейпирования для исходящего канала по данной сервисной связке (например, при достижении трафиком нижней границы шейпирования);

–Изменение ширины исходящего канала

выполняется для каждой IP-группы при смене условий шейпирования для исходящего канала по данной сервисной связке;

–Снятие ограничений на исходящий канал

выполняется для каждой IP-группы при выходе исходящего канала по данной сервисной связке из-под условий шейпирования;

–Закрытие файла детальной статистики

выполняется для файла детальной статистики при его закрытии;

–Закрытие файла логов

выполняется для log-файла при его закрытии;

–Внесение платежа

выполняется при внесении платежа;

–Новая DHCP аренда

выполняется при выдаче нового IP-адреса;

–Обновление DHCP аренды

выполняется при обновлении аренды IP-адреса;

–Истечение DHCP аренды

выполняется при истечении аренды IP-адреса;

–Добавление связки IPTV

выполняется при создании сервисной связки IPTV;

–Изменение связки IPTV

выполняется при изменении сервисной связки IPTV;

–Удаление связки IPTV

выполняется при удалении сервисной связки IPTV;

–Добавление связки Видео по запросу

выполняется при создании сервисной связки Видео по запросу;

–Изменение связки Видео по запросу

выполняется при изменении сервисной связки Видео по запросу;

–Удаление связки Видео по запросу

выполняется при удалении сервисной связки Видео по запросу;

–Запись в отчёт Изменения пользователей

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

Преобразование правил#

Преобразование правил брандмауэров, созданных в UTM сборки 5.2.1-006 или ранее, производится вручную.

Брандмауэр#

Брандмауэр – это объект системы, предназначенный для идентификации аффектора, коммутатора или поставщика NetFlow.

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

Брандмауэр обладает следующими параметрами:

–Идентификатор брандмауэра

задается автоматически.

–Тип

Локальный, если команды будут исполняться локально, или Cisco (rsh), если команды будут передаваться по протоколу rsh. Тип брандмауэра должен соответствовать параметру firewall_type конфигурационного файла RFW, сопоставляемого с данным брандмауэром.

–Наименование

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

–IP

адрес поставщика NetFlow, указываемый в свойствах IP-группы.

–Логин

логин, используемый в качестве remote login при авторизации по rsh. Только для типа брандмауэра Cisco (rsh). В качестве local login всегда передаётся netup.

–Комментарий

носит информационный характер.

Сценарий создания брандмауэра описан в примере Создание брандмауэра.

Настройка службы utm5_rfw#

Исполняемый файл utm5_rfw называется /netup/utm5/bin/utm5_rfw .

В командной строке можно передавать следующие параметры:

В UNIX-системах существует 3 способа запуска utm5_rfw:

1.Непосредственный запуск бинарного файла /netup/utm5/bin/utm5_rfw с необходимыми параметрами.

2.Запуск с помощью скрипта watchdog с указанием параметра start:

 
В этом случае исполняемому файлу будет передан параметр -f. Скрипт автоматически перезапустит utm5_rfw в случае, если он по каким-либо причинам некорректно завершит работу.

3.Запуск с помощью скрипта автоматического запуска (рекомендуемый способ).

в Linux:

в FreeBSD:

В этом случае произойдет запуск скрипта watchdog.

Для остановки utm5_rfw и скрипта watchdog следует выполнить команду:

в Linux –

в FreeBSD –

Для запуска RFW на удалённой машине необходимо, чтобы параметры core_host и core_port в его конфигурационном файле соответствовали адресу и порту, которые используются ядром UTM5 для соединения по протоколу Stream.

На одной машине может одновременно работать несколько RFW с различными конфигурационными и PID-файлами.

Конфигурационный файл#

По умолчанию UTM5 RFW использует конфигурационный файл /netup/utm5/rfw5.cfg.

Формат конфигурационного файла:

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

Ниже приведён список возможных параметров.

Параметры журналирования (подробнее см. в разделе Журналирование):

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

Синхронизация правил#

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

Флаги синхронизации (возможные значения перечислены ниже) задаются параметром конфигурационного файла sync_flags или параметром командной строки -s, причём последний имеет приоритет. Можно одновременно использовать несколько флагов, разделяя их двоеточиями.

–enable – выполнить правила, ассоциированные с событием "Включение Internet";

–disable – выполнить правила "Выключение Internet";

–users – выполнить правила "Добавление пользователя";

–iptraffic – выполнить правила "Добавление связки IP-трафика";

–dialup – выполнить правила "Добавление связки dialup";

–blocks – выполнить правила "Изменение типа блокировки";

–shaping – выполнить правила "Установление ограничений dynashape".