[myst]

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

 

Дабы не сочинять заново эту наркоманию, скидываю набросок ТЗ для программистов:

 

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

Существует распределенная сеть с топологией "звезда" весь трафик (в том числе и в сторону Интернета) с лучей (Филиал) сходится в центр (Региональный узел, РУ). В центре интернет трафик с помощью policy routing`a заворачивается на сервер подсчета трафика и авторизации. На данный момент роль сервера выполняет Windows сервер с Kerio Connect. Kerio выполняет роли: а) Авторизации доменных пользователей AD б) Подсчета статистики доменных пользователей в) Статистика по посещенным ресурсам г) Различные списки доступа для разных AD гупп пользователей. 

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

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


Техническое задание на разработку портала авторизации, подсчета трафика, ACL, WEB интерфейса для просмотра статистики и управления конфигурацией:

- Реализовать доступ пользователей в интернет с авторизацией в WEB интерфейсе.
 - WEB интерфейс должен представлять собой оформленную WEB страницу с полями ввода Логина и Пароля (домен должен подставляться автоматически в соответствии с настройкой) и логотипом компании.
- Реализовать подсчет трафика по IP с привязкой к Domain Login пользователя в AD.
 - Информация по трафику с определенного IP адреса за определенный промежуток времени должна быть привязана к Логину пользователя авторизовавшегося в этот промежуток в ремени с этого IP адреса. Информация по трафику должна содержать в себе IP адрес посещенного ресурса, порт, и доменное имя (если это возможно), а так же количество скачанных/переданных байт, дату и продолжительность сессии.
- Реализовать "Контейнеры", где в качестве контейнера является подсеть филиала.
 - "Контейнер" - условное понятие означающее возможность создания групп статистики на основе подсети филиала. Любой пользователь прошедший аутентификацию с подсети (контейнера), должен быть внесен в статистику этого филиала. Для контейнеров обязательно должна быть предусмотрена как общая статистика трафика на контейнер (подсеть), так и дифферинцированная статистика по отдельным пользователям. 
- Реализовать дифферинцированные списки доступа (ACL, правила фаервола) для разных групп пользователей AD.
 - Необходимо реализовать создание правил доступа в интернет с возможностью ручной группировки их по определенным признакам, возможностью привязки как отдельных так и с группированных ACL как к группам пользователей в AD, так и к отдельным пользователям. Все настройки должны быть доступны как из WEB интерфейса, так и из конфигурационного файла. 
- Реализовать группу "Superadmin" для управления конфигурацией и просмотра статистики по всем контейнерам.
 - Должна быть предусмотренна возможность назначения привелегий для управления конфигурацией, просмотра всей статистики определенной группе AD. На случай потери связи с доменом, необходимо так же создать локального пользователя с полными правади доступа.
- Реализовать дифферинцированный доступ к контейнерам. Управляющий магазина имеет доступ только к статистике своего контейнера.
 - Необходимо реализовать возможность назначения пользователю привелегии локального администратора в пределах своего контейнера. Локальный администратор должен иметь право просмотра статистики по своему контейнеру.
- Реализовать контроль доступа не только по IP адресам назначения, портам, IP адресам источника, но и по URL/Regexp шаблону.
 - Правила фаервола (ACL) должны обладать следующим функционалом: Разрешение доступа/блокировка по адресу назначения/источника(должна быть возможность группировки IP адресов в именнованный пул). Разрешение доступа/блокировка по адресу порта (должна быть возможность группировки портов в именнованный пул). Разрешение/блокировка по URL сайта и шаблону.
- Реализовать WEB интерфейс для настройки всех возможных параметров данного портала.
 - Для всех настроек, необходимо предусмотреть WEB интерфейс. WEB интерфейс должен иметь соответствующии разграничения прав доступа для пользователей (superadmin - могут все, администратор контейнера - статистика в рамках контейнера, региональный администратор - просмотр общей статистики РУ по всем контейнерам). 
- Реализовать текстовые конфигурационные файлы для настройки всех элементов.
 - Помимо WEB интерфейса, все изменяемые параметры должны храниться в человекочитаемых текстовых файлах конфигурации. В качестве примера можно взять squid.conf
- Реализовать различные фильтры для просмотра статистики по пользователю/контейнеру за день, месяц, год.
 - WEB интерфейс должен иметь возможность фильтрации отображения статистики по пользователю, контейнеру, дате, суммарной статистике.
- Реализовать возможность разворачивания дистрибутива из образа с минимальными действиями со стороны Системных Администраторов на типовое (стандартизированное) железо.
 - На "выходе", проект должен представлять из себя загрузочный ISO образ операционной системы с предустановленным и преднастроенным порталом. Для холодного старта портала, необходимо минимальное число настроек (IP адреса интерфейсов, сервер AD, аутентификационные данные). Образ должен иметь минимальный интерактивный CLI интерфейс для установки на компьютер. 
- Написать документацию по настройке/обслуживанию портала.
 - Должна присутствовать документация по всем возможным настройкам портала авторизации.
- Написать документицию по принципам работы каждого модуля портала в отдельности.
 - Должна присутствовать документаци по логике работы каждого модуля портала в отдельности.
- Предусмотреть возможность добавления функционала ввиде модулей.
 - Необходимо реализовать возможность добавления модулей с дополнительным функционалом. Добавление модуля должно вызывать минимум изменений в логике работы остальных модулей.
- Предусмотреть 2 типа баз пользователей - ActiveDirectory и Local с привязкой к статическому IP адресу.
 - Портал должен уметь аутентифицировать одновременно два типа пользователей - ActiveDirectory пользователи и Пользователи заведенные вручную локально. 
- Реализовать возможность привязки ACL как к AD группе пользователей, так и к отдельным доменным пользователям и к локальным пользователям.


Как это вижу я:
Есть сервер авторизации на базе линукса, который по LDAP подключен к домену.
Поскольку по логину считать невозможно, необходимо как то срастить время логина/логоф пользователя со статистикой netflow для его IP адреса. Возможно при авторизации в WEB интерфейсе текущий IP адрес пользователя (в сети используется DHCP), пишется в какую-либо локальную базу и устанавливается время жизни сессии. Потом разгребается статистика netflow, по времени сращивается с логином/логофом, и пишется уже в базу статистики.
Соответственно нужны какие-то ACL (Или например правило NAT/Forwarding) с контролем активности с IP адреса и возможности отключения пользователя в случае не активности/истечении таймера c записью события отключения в базу.
Все остальное в рамках ТЗ.
Если будут более правильные способы реализации моих "хотелок" - я возражать не буду.

 

Из этого опуса в принципе понятно что мне надо.

 

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

 

Кто что может посоветовать?

Сейчас смотрю в сторону Cisco IronPort S170

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

 

Заранее спасибо за подсказки.

Изменено 18 марта, 2014 пользователем myst

[alibek]

Хотспот с интеграцией AD что-ли нужен?

[myst]

Хотспот с интеграцией AD что-ли нужен?

Ну если сильно грубо то да.

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

Изменено 18 марта, 2014 пользователем myst

[Ivan_83]

Форефонт какой то был, если мс ещё его пилит.

[dazgluk]

Ideco ICS не подходит?

[myst]

Форефонт какой то был, если мс ещё его пилит.

1) TMG Rip

2) Это крайне неадекватное поделие, под нагрузкой превращается в тыкву

3) Шило на мыло менять (ТМГ на Керио) смысла чуть более чем нет вообще

 

Ideco ICS не подходит?

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

[Ivan_83]

Реализовать подсчет трафика по IP с привязкой к Domain Login пользователя в AD.

Удобная привязка была только в ISA/TMG при использовании ихнего агента, там же можно было даже смотреть что за софтина лезет и даже блочит/пробрасывать ей порты.

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

 

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

Те оно просто описывает функционал вашей любимой керии и на нём замыкается.

 

Начните с простого: разделите его на части

1. работа со статистикой

2. учёт трафика

3. управление доступом

4. администрирование

 

Контейнеры - в топку.

 

1, 2. Со статой всё просто: пишем в базу и из базы дёргаем запросами что нужно.

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

 

3. После того как мы всех привязали к IP то можем просто где то в базе хранить и правила.

Дёргаем их из базы по крону/эвенту и загружаем в фаервол.

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

В его логов можно тоже в базу пулять урлы, для ещё большего её захламления.

 

4. Какой то там веб интерфейс к базе по типу как со статой.

[myst]

Удобная привязка была только в ISA/TMG при использовании ихнего агента, там же можно было даже смотреть что за софтина лезет и даже блочит/пробрасывать ей порты.

Агент к сожалению невозможен. В принципе.

 

 

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

Те оно просто описывает функционал вашей любимой керии и на нём замыкается.

 

Ну вопервых ТЗ это набросок, к томуж он описывает многое что он не умеет керио.

Я сразу оговорился, что он дает лишь общее представление о том что мне надо.

 

 

Начните с простого: разделите его на части

1. работа со статистикой

2. учёт трафика

3. управление доступом

4. администрирование

 

Уже редактирую.

Контейнеры - в топку.

Это одно из основных условий. Возможность группировки статистики/списков доступа/настроек по филиалам.

 

1, 2. Со статой всё просто: пишем в базу и из базы дёргаем запросами что нужно.

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

 

3. После того как мы всех привязали к IP то можем просто где то в базе хранить и правила.

Дёргаем их из базы по крону/эвенту и загружаем в фаервол.

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

В его логов можно тоже в базу пулять урлы, для ещё большего её захламления.

 

4. Какой то там веб интерфейс к базе по типу как со статой.

 

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

По этому нужна именно связка логин+ip на время сессии.

Такие дела.

[Ivan_83]

Группировка на основе запроса в бд.

Те сделать плоскую структуру а не иерархическую.

 

vpn, authpf, ident или какой то аналог. Может быть 802.1x, не вдавался как оно с доменом взаимодействует.

Ещё IPSec там есть, но тоже хз как с удостоверением юзера он связан.

Ещё NAP - чисто вендовое, может от туда можно что то о юзере извлекать.

 

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

[myst]

Группировка на основе запроса в бд.

Те сделать плоскую структуру а не иерархическую.

 

vpn, authpf, ident или какой то аналог. Может быть 802.1x, не вдавался как оно с доменом взаимодействует.

Ещё IPSec там есть, но тоже хз как с удостоверением юзера он связан.

Ещё NAP - чисто вендовое, может от туда можно что то о юзере извлекать.

 

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

Вы не поняли. Это очень большая, географически разнесенная корпоративная сеть. ВПН вообще не рассматривается.

Если бы он был возможен, я бы давно реализовал это сам. В том и проблема.

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

 

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

Вот советовали смотреть Allot NetEnforcer и SourceFire Application Control. Но к сожалению документации по этим штукам почти нет. Понять то ли это крайне сложно.

Изменено 19 марта, 2014 пользователем myst