При использовании модуля dhcp первичная авторизация происходит по мак адресу. Особенность в том, что не только по указанному в админке, но подходит и мак адрес, который ранее получал ip адрес.
То есть, если подменить мак адрес на любой из существующий в пользовательской сети, то можно получить ip который присваивался ранее и ip привязка будет к аккаунту у которого ранее был данный ip, вне зависимости от сведений в option 82.
Получается, что option 82 в качестве безопасной идентификации пользователя, в данной реализации dhcp модуля не подходит.
Вопрос:
1. Какими костылями можно это исправить?
DHCP модуль + option 82
Re: DHCP модуль + option 82
Включить DHCP snooping и Dynamic ARP Protection с привязкой к порту/vlan коммутатора, не забываем про трастовые порты по итогу конкретный мак сможет работать только из конкретного порта или vlan (что собственно и есть опция 82), такой же мак на другом порту и вилане работать не будет, айпишка назначенная вручную с подменным маком тоже работать не будет, левый DHCP сервер выдать поддельные параметры опции для обхода snooping работать не будет, в общих чертах - это не проблема биллинга, а проблема реализации архитектуры сети и настройки защит на коммутаторах.Jonson писал(а):При использовании модуля dhcp первичная авторизация происходит по мак адресу. Особенность в том, что не только по указанному в админке, но подходит и мак адрес, который ранее получал ip адрес.
То есть, если подменить мак адрес на любой из существующий в пользовательской сети, то можно получить ip который присваивался ранее и ip привязка будет к аккаунту у которого ранее был данный ip, вне зависимости от сведений в option 82.
Получается, что option 82 в качестве безопасной идентификации пользователя, в данной реализации dhcp модуля не подходит.
Вопрос:
1. Какими костылями можно это исправить?
Если бы так, но проблема именно в отработки биллингом и ни DHCP snooping, ни Dynamic ARP Protection тут не помогут.
DHCP snooping пропускает тот ip который прислал DHCP (выдал биллинг), поэтому он в данной ситуации не помогает. DHCP snooping поможет от тупой подмены ip. А в данной ситуации на порту коммутатора DHCP snooping получает данные от трастового DHCP и считает что все хорошо.
C Dynamic ARP Protection примерно та же ситуация.
Поясняю на коммутаторах работает снупинг с опц82 и релей, он отправляет запрос на ip от мака оригинального или подмененного, а dhcp возвращает ответ с ip для запросившего мака.
Поэтому настойки безопасности на коммутаторе тут никак не влияют.
DHCP snooping пропускает тот ip который прислал DHCP (выдал биллинг), поэтому он в данной ситуации не помогает. DHCP snooping поможет от тупой подмены ip. А в данной ситуации на порту коммутатора DHCP snooping получает данные от трастового DHCP и считает что все хорошо.
C Dynamic ARP Protection примерно та же ситуация.
Поясняю на коммутаторах работает снупинг с опц82 и релей, он отправляет запрос на ip от мака оригинального или подмененного, а dhcp возвращает ответ с ip для запросившего мака.
Поэтому настойки безопасности на коммутаторе тут никак не влияют.
Только в том случае если первичная идентификация идет по опции, а продление сессии по маку.Jonson писал(а):Когда ты используешь opt82, а идентификация происходит по маку это нормально?Nik0n писал(а):Ну конечно для биллинга Opt82 это средство "идентификации" клиента.
Хочешь безопасность - настраивай коммутатор доступа.
Я считаю что тут все верно.
Но речь не о продлении сессии, а о том что после окончания сессии мак-адрес имеет возможность получить тот же ip и получить привязку к логину, ранее получавшему данный ip, без проверки opt82.Nik0n писал(а):ISC DHCP сервер с такой же логикой работает.adeep писал(а): Только в том случае если первичная идентификация идет по опции, а продление сессии по маку.
Допустим у меня логин №1 и порт №1 я прошел идентификацию с маком №1 и получил ip №1, сессия окончилась, но ip еще никто не занял, я пошел к соседу у которого логин №2 и порт №2, но там меня не проверяют на opt.82 и я получаю ip №1 и привязку к логину №1
Вы сейчас описали поведение при выключенном DHCP snooping на конечном коммутаторе, при включенном IP выдаваться не будет, т.к. запрошен с другого порта и при этом должен быть запрос DHCP с включенной опцией.Jonson писал(а): Допустим у меня логин №1 и порт №1 я прошел идентификацию с маком №1 и получил ip №1, сессия окончилась, но ip еще никто не занял, я пошел к соседу у которого логин №2 и порт №2, но там меня не проверяют на opt.82 и я получаю ip №1 и привязку к логину №1
У вас в сети только один коммутатор доступа?Rico-X писал(а):Вы сейчас описали поведение при выключенном DHCP snooping на конечном коммутаторе, при включенном IP выдаваться не будет, т.к. запрошен с другого порта и при этом должен быть запрос DHCP с включенной опцией.Jonson писал(а): Допустим у меня логин №1 и порт №1 я прошел идентификацию с маком №1 и получил ip №1, сессия окончилась, но ip еще никто не занял, я пошел к соседу у которого логин №2 и порт №2, но там меня не проверяют на opt.82 и я получаю ip №1 и привязку к логину №1
Когда аренда истекла коммутатором заново запросится OPT82, без этого доступа у пользователя в сеть не будет, что у вас за коммутаторы такие, которые этого не умеют, стандартное поведение при активном снупинге.Jonson писал(а):К тому же на коммутаторе уже не будет привязки ip-mac на порту, когда аренда истекла.
Нет около 900 на доступе, что это меняет если у них разные cid? В опции передается cid и rid которые однозначно определяют: коммутатор, порт, vlan и прочие параметры для доступа пользователя, если хоть один из них изменится, то доступ пользователь не получит. У вас же по описанию какая-то хрень получается, типа один умный в голове на которых настроена опция, а дальше куча мыльниц, что не могут контролировать место входа юзера.Jonson писал(а):У вас в сети только один коммутатор доступа?Rico-X писал(а):Вы сейчас описали поведение при выключенном DHCP snooping на конечном коммутаторе, при включенном IP выдаваться не будет, т.к. запрошен с другого порта и при этом должен быть запрос DHCP с включенной опцией.Jonson писал(а): Допустим у меня логин №1 и порт №1 я прошел идентификацию с маком №1 и получил ip №1, сессия окончилась, но ip еще никто не занял, я пошел к соседу у которого логин №2 и порт №2, но там меня не проверяют на opt.82 и я получаю ip №1 и привязку к логину №1
Или вы банально не прочитали суть проблемы, что опция 82 проверяется только один раз для каждого мака (возможно проверяется еще раз, если его ip займут пока он будет в офлайнет - этого я не уточнял), потом если он есть в истории utm сверка проходит только по мак адресу и соответствие к пулу (опц.82 не проверяется)