[morf]

Доброго дня!

Имею сеть построенную на des-3526/3028 коммутаторах на уровне доступа. Встал вопрос о контроле доступа к сети.

После множества перечитанных мануалов решено аутентифицировать абонентов на уровне коммутаторов L2 через 802.1x MAC-Based с использованием radius'a (FreeRadius).

Почему Mac-based ? Потому, что есть порты в которые подключены обычные "мыльницы".

Понятно, что в базе радиуса хранятся mac-адреса абонентов, и коммутатор просто ищет MAC. А есть-ли возможность у вендора указать такой атрибут, который проверял не только МАК, но и ПОРТ и КОММУТАТОР.

 

Что думаете по-поводу 802.1x, уважаемые гуру? Может у кого есть опыт в развертывании такого доступа. В принципе меня устроило бы и функция IP-MAC-PORT Binding, но опять же это костыли (писать скрипты, которые будут мониторить таблицу коммутаторов и бла-бла), необходимо нечтоо централизованное, как 802.1x.

Спасибо!

Изменено 6 июля, 2011 пользователем morf

[darkagent]

"мыльницы"

не майтесь дурью, первым делом избавьтесь от хлама, потом 802.1x port-based. иначе тех.поддержка ваша вас люто возненавидит.

[morf]

"мыльницы"

не майтесь дурью, первым делом избавьтесь от хлама, потом 802.1x port-based. иначе тех.поддержка ваша вас люто возненавидит.

С радостью, но в некоторых местах это просто невозможно :) С другой стороны mac-based полностью решает проблему.

Тем не менее, если есть технология, значит она применима.

Поделитесь пожалуйста опытом.

Изменено 6 июля, 2011 пользователем morf

[darkagent]

mac-based

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

благо, сам себе провайдер, и такое ереси не допускаю.

[morf]

Хорошо, тогда расскажи мне, как ты у себя в сети контролируешь подмену mac/ip, как отслеживаешь несанкционированные подключения?

Потом вернемся к моему вопросу.

[terrible]

Google -> DHCP Snooping

[darkagent]

маки? зачем контролировать маки?

1 абонент на 1 порт и тотальный учет...

 

DHCP Snooping

тоже хотел указать, но dhcp не считаю обязательным...

[s.lobanov]

Google -> DHCP Snooping

 

Сказав А, надо говорит и Б. Сам dhcp snooping это лишь защита от фальшивых dhcp-серверов и составление таблички биндингов.

Чтобы защититься от поддельных mac,ip и arp-spoofing'а нужно ещё включать mac verification, ip source guard и arp inspection. И ещё важно понимать, что dhcp snooping и arp inspection это софтовые фичи(происходит копирование(trapping) dhcp и arp-трафика на cpu). У dlink'а есть функционал защиты cpu с per-port счётчиками?

[morf]

1 абонент на 1 порт и тотальный учет...

Пусть так. Но, в чем защита от поддельных mac/ip ? Средствами чего ты ее реализуешь?

 

PS Неужели 802.1x Port или Mac Based + Radius - некатируемая технология? Ведь со стороны абонента не обязательно иметь поддержку 802.1x протокола, а весь процесс аутентификации возлагается на radius сервер.

[darkagent]

Пусть так. Но, в чем защита от поддельных mac/ip ? Средствами чего ты ее реализуешь?

 

PS Неужели 802.1x Port или Mac Based + Radius - некатируемая технология? Ведь со стороны абонента не обязательно иметь поддержку 802.1x протокола, а весь процесс аутентификации возлагается на radius сервер.

802.1x port-based потребует от вас таки 1 порт на 1 абонента. mac-based заставит вашу тех.поддержку срать кирпичами.

[morf]

Спасибо за ответы!

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

- на уровне доступа 3526/3028

- не везде "port-абонент", в большинстве портов могут находится несколько маков.

[darkagent]

- не везде "port-абонент", в большинстве портов могут находится несколько маков.

переделать на "port-абонент", влепить port-sec на 2 мака, дальше тотальная инвентаризация и 802.1x port-based.

[morf]

тотальная инвентаризация и 802.1x port-based.

А с технической стороны как это выглядит? Обязательная-ли поддержка 802.1x со стороны в таком случае? В каком виде атрибуты вылятся на радиус-сервер ?

[darkagent]

А с технической стороны как это выглядит?

 

Обязательная-ли поддержка 802.1x со стороны в таком случае?

Если ориентируемся на 802.1х port-based, то технически это выглядит так:

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

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

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

одно но - строго следите за тем как происходит монтаж/коммутация, чтоб не получилось так что вы считаете что порт 1 на коммутаторе А это один абонент, а на деле это совсем другой абонент, а нужный вам висит на порт 9 коммутатора Б.

 

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

документацию рекомендую почитать.

[morf]

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

При этом абоненту не обязательно иметь поддержку 802.1х ?

[darkagent]

При этом абоненту не обязательно иметь поддержку 802.1х ?

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

[denistt]

Добрый день,подскажите проблема с 802.1x auth_mode mac_based на 3028 решилась или нет????

[xcme]

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

Апну древность. Читаю документацию D-Link и везде написано, что у клиента должно быть установлено специально ПО. Как же заставить 802.1x работать прозрачно, без настройки клиентской стороны?

[Andrei]

Жесть... :) Последние с сообщения с интервалом 3 и 2 года :)

[s.lobanov]

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

Апну древность. Читаю документацию D-Link и везде написано, что у клиента должно быть установлено специально ПО. Как же заставить 802.1x работать прозрачно, без настройки клиентской стороны?

 

Специально ПО нужно на тех ОС, где его нет из коробки. Точно так же как в Windows 95/98 требовалось ставить PPPoE-клиент

 

На Win7 и MacOS X окно авторизации 802.1x вылезет само, если всё по дефолту. Как оно в восьмерочке или десяточке не скажу

[ShyLion]

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

Авторизация по маку это нестандартное решение, у каждого вендора свое.

Соответственно для 802.1x на конечном узле должно быть специальное ПО называемое supplicant, а для авторизации по маку на клиенте не нужно ничего. В версиях винды, начиная с XP сервис пакака какого-то там, саппликант является частью системы.

[xcme]

Этсамое... не нужно смешивать мух и котлеты. 802.1x никакого отношения к авторизации по макам не имеет. Совсем.

Т.е. MAC-Based 802.1х просто отличает клиентов по MAC, но не авторизует их?

 

p.s. Вообще я ищу способ назначить vlan при помощи radius, который при этом будет полностью прозрачен для клиента. Это можно сделать в D-Link при помощи MAC-based Access Control?

[ShyLion]

Этсамое... не нужно смешивать мух и котлеты. 802.1x никакого отношения к авторизации по макам не имеет. Совсем.

Т.е. MAC-Based 802.1х просто отличает клиентов по MAC, но не авторизует их?

 

p.s. Вообще я ищу способ назначить vlan при помощи radius, который при этом будет полностью прозрачен для клиента. Это можно сделать в D-Link при помощи MAC-based Access Control?

 

В случае 802.1х MAC это просто один из аттрибутов в составе RADIUS пакета, основной обмен идентификационной информацией происходит между конечным узлом (абонентом) и сервером доступа, в любом случае у клиента должен быть саппликант.

 

Про d-link ничего не скажу, к счастью этого чуда не используем.

 

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

Изменено 3 февраля, 2016 пользователем ShyLion

[xcme]

Про d-link ничего не скажу, к счастью этого чуда не используем.

Вообще сам D-Link вот что пишет:

MAC-Based 802.1х

 

В отличие от аутентификации 802.1X на основе портов, где один порт, авторизированный клиентом, остается открытым для всех клиентов, аутентификация 802.1X на основе МАС-адресов (MAC-Based 802.1X) – это аутентификация множества клиентов на одном физическом порте коммутатора. При аутентификации 802.1X на основе МАС-адресов проверяются не только имя пользователя/пароль, подключенных к порту коммутатора клиентов, но и их количество. Количество подключаемых клиентов ограничено максимальным количеством MAC-адресов, которое может изучить каждый порт коммутатора. Для функции MAC-Based 802.1X количество изучаемых МАС-адресов указывается в спецификации на устройство. Сервер аутентификации проверяет имя пользователя/пароль, и если информация достоверна, аутентификатор (коммутатор) открывает логическое соединение на основе MAC-адреса клиента. При этом, если достигнут предел, изученных портом коммутатора МАС-адресов, новый клиент будет заблокирован.

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

 

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

Вот как раз номер порта и интересен, а информацию о MAC можно игнорировать. Но, как я понял, vlan при помощи Radius можно назначить только для 802.1x, а это прозрачно сделать не получится.

[ShyLion]

Ничто не мешает вендору по обнаружению неавторизованого МАКа на порту, спросить у радиуса можно ли дать доступ и в какой вилан его определить. Набор атрибутов, которые он пошлет на радиус целиком зависит от вендора.

Просто в случае 802.1x (полноценного), абонент кроме МАКа предъявит еще что-то более существенное, сертификат, или логин-пароль и т.п. Сам механизм 802.1х для коммутатора при этом прозрачен в плане того, как клиент доказывает серверу доступа свою личность. Конечно ничто не мешает легитимному хосту пропасть а на его месте с тем-же маком появиться злоумышленнику, но в случае парвильного подключения порт-абонент будет сброс линка == переавторизация, плюс может быть автоматическая периодическая переавторизация по инициативе коммутатора (саппликант всегда на готове и слушает такие запросы).

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