Говорят  великая китайская стена не столько защищала Китай от внешних агрессий, сколько осложняло вывоз награбленного кочевниками. Быстро перебраться через стену с честно отнятым добром едва ли представляется тривиальной задачкой.
  Учет тысячелетнего  китайского опыта борьбы в настройках файрвола предлагает фильтровать соединения идущие не только на охраняемый девайс, но и от него. Иными словами, если серверу не надо лезть в интернет, то нужно запретить это делать. Даже если сервер пробит эксплоитом, то все равно получить устойчивое взаимодействие с внедренным шелом у злоумышленника не получится, ну или будет крайне не просто.
  Для критических задач это лучше сделать за правило, а некие произвольные взаимодействия организовывать через прокси сервера. Что-то вроде прокси должно было быть и у китайцев.

Всем хорош FreeRadius , но все какие-то плосковатые happy story мне попадались.
А если нужно котролировать  Dialup, VPN, WiFi, 802.1x и во всех случаях разные пользователи, пароли, атрибуты, параметры....
Придется ставить множество radius серверов, резервировать, бекапировать....

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

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

Берем стандартный freeradius плагин для  хранения аккаунтов пользователей в MySQL.
Видим, что есть таблица хранения NAS ов, таблицы для персональных пользовательских параметров проверки/установки и точно такие-же данные в таблицах для групп. Конечно же, есть таблица-связка пользователя и группы. Гвоздь программы:  возможность самостоятельного задания SQL запросов в конфигурационном файле и мапирование  атрибутов  Radius запросов на  SQL.

На всякий случай смотрим на Radius запрос,  причем самый клинический, c WiFi (тоесть с меткой про SSID: "VIP"):

       User-Name = "dima"
       Calling-Station-Id = "00-1B-21-C1-D2-62"
       Called-Station-Id = "00-16-C7-21-3F-C3:VIP"
       NAS-Port = 29
       NAS-IP-Address = 10.0.7.104
       NAS-Identifier = "Cisco_fa:33:1b"
       Airespace-Wlan-Id = 4
       Service-Type = Framed-User
       Framed-MTU = 1300
       NAS-Port-Type = Wireless-802.11
       Tunnel-Type:0 = VLAN
       Tunnel-Medium-Type:0 = IEEE-802
       Tunnel-Private-Group-Id:0 = "975"
       EAP-Message = 0x02020009016c656e51
       Message-Authenticator = 0x5d1c50b996593ec2dec21dc5d481214e
 
Нас интересуют NAS-IP-Address (содержит адрес  NAS, в данном случае Cisco контроллера WiFi)  и Called-Station-Id ( содержащую MAC адрес access  point-а и отметку о SSID :  "00-16-C7-21-3F-C3:VIP" ).

Теперь внедряем понятие ServiceID в таблицы и запросы. В таблице NAS вносим поля CalledStation и ServiceID. В таблицах radcheck, radgroupcheck,radreply,radgroupreply добавляем поле ServiceID. В SQL запросах вносим связку по serviceID (на примере таблице radcheck):

SELECT...WHERE...
and nas.serviceid=radcheck.serviceid
and nas.nasname='%{NAS-IP-Address}'  
and nas.calledstation=RIGHT('%{Called-Station-Id}',LENGTH(nas.calledstation))

Внимание на последнюю строку выше. Правая часть параметра "Called-Station-Id" из radius запроса сравнивается с полем СaledStation в таблице NAS. Размер правой части береться из того же поля таблицы. В случае с WiFi и SSID=VIP, если в таблице NAS внести в поле CalledStation значение ":VIP", то мы будем сравнивать его с 4-мя правыми символами параметра "Called-Station-Id" из  radius запроса. При работе с WiFi для каждого SSID получим уникальный сервис со своими пользователями и группами. Если же CalledStation пустой, то "Called-Station-Id"  из запроса вообще не учитывается и идентификатор сервиса будет зависеть только от "NAS-IP-Address" radius запроса.
А если указать в CalledStation в таблице NAS  будет содержать и MAC адрес, то получаем сервис только для конкретного access point-а -  пока не знаю как относится к этому, то ли побочный эффект, то ли фича.

Что мы имеем:
1) Имеем понятие идентификатора сервиса.
2) Для каждого идентификатора сервиса имеются   пользователи и группы, независимые от других сервисов.
3) Идентификатор сервиса зависит от  IP адреса NAS и опционально от параметра Called-Station-Id.

На одном Radius сервере получили полное и независимое управление аккаунтами для практически неограниченного количества сетевых сервисов. Правил только sql.conf и таблицы в MySQL. Все!



Забыл подводную граблю. При работе с WiFi и использовании PEAP необходимо для  PEAP в файле  eap.conf указать  опцию:
 copy_request_to_tunnel = yes
Дело в том, что при работе с  PEAP внутри radius сервера проходит создание нового  radius запроса на основе EAP сообщения в изначальном Radius запросе.
Если не указать copy_request_to_tunnel  то внутренний radius запрос получится куцым, без полей "Called-Station-Id" и "NAS-IP-Address", а они критичны в нашей многоликости.

А очевидно то, что IDS необходимо располагать в точке взаимодействия с внешними сетями, по default маршруту.   Меня больше волнует всякого рода активность внутренней сети и на самом популярном маршруте самое место  этому IDS, можно легко получить информацию о почти всем проблемном трафике внутренней сети и в одной точке. Явления вирусов в сети как на ладони.

Сплошная экономия сил и денег.

Фиксация внешних "доброжелателей"  на этом маршруте совсем уж очевидна.

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

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

1) Единое информационное пространство 2) Максимальная безопасность всех участников 3) Простота реализации и поддержки на практики этой модели

Все пункты важны, но особые разногласия вызывает именно 1-й. Речь идет именно об информации, или нечто выше  7-ого уровня  модели OSI ;-) .  Никакого отношения к  L3,L4 (TCP/IP) единое информационное пространство не имеет.  Внутренняя уверенность  в этом просто необходима, так  как придется  убеждать  других. Максимальная безопасность на сетевом уровне всегда сводится к минимизации возможных сетевых взаимодействий до уровня необходимых (грубо так). В большой корпоративной сети количество участников слишком большое, чтобы попытаться проявлять индивидуальный подход к каждому участнику или даже группе. Количество возможных пар участников сетевых взаимодействий астрономическое,  а выполнять пункт 2 как-то надо. Простота - гарантия выполнения  как раз 2-го и 1-го  пунктов. Простота - сведения к минимуму возможных моделей поведения и их упрощения. Да, собственно и модель взаимодействий приблизительно известна . Клиент - Сервер.

Ограничив сетевые взаимодействия клиента только серверами мы максимально эффективно решаем все наши проблемы. Технически реализовать такой подход крайне просто, описав на роутящем клиентов сетевом оборудовании  IP адреса сегментов серверов в разрешенных и  запретив все остальное. На Cisco вообще получится  один общий ACL  на входящие пакеты для  всех интерфейсов - очень удобно. Все это реализуется на любом  сетевом оборудовании с простейшей пакетной фильтрацией. Это еще и весьма бюджетное решение.

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

У достоинствах все. О недостатках:

Сопротивление при внедрении ! Наверняка существует прямой сетевой обмен между рабочими местами. Доводов будет много  у других ИТ специалистов и не только : Это же так просто сделать. Это уже работает. Это просто необходимо. Это должно стоять у меня на столе. ИТД ИТП. Чтож, придется выкручиваться, толи переводить обмен на сервера, толи вытаскивать недосервера виланами в IP адреса  сегмента серверов. Последнее, что нужно делать, так исключения. Будет очень не просто.  Будьте злопамятны ( или записывайте ;-) ) все инциденты, которые были бы предотвращены при правильном подходе.

Еще об исключениях:Для кого сделать исключения  ? Думаю достаточно только для сетевых администраторов. Если Вы или Ваши люди не испытывают в это реальной необходимости, лучше и себя прикрыть ( о себе как о IT security). Ваши риски что-то подцепить в сети будут выше, чем у других, есть неприятный  шанс появится  в редких сводках по проишествиям. Ну можно исключить и протоколы, напрмер ICMP или при массовом использовании VoIP придется пропускать большой диапазон UDP (RTP) .  Универсальность правил фильтрации для клиентских сегментов облегчит внесение  подобного рода изменений.

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