По умолчанию RADIUS авторизует по протоколу PAP и пароли UTM хранит в зашифрованном виде в базе.
Наверное при DialUp их не особо подслушаешь, а что касается подключений по VPN из локальной сети то наверное это легко сделать если не разделять пользователей по VLAN.
Если поставить CHAP авторизацию то в мануале написано пароли будут храниться в открытом виде в базе чем ето плохо?
И еще вопрос кто переходил с PAP на CHAP какие процессы происходят? Изинил я допустим в конфигурационном файле метод хранения паролей и авторизацию... Пользователи смогут зайти (как написано в мануале) в WEB интерфейс чтобы сменить пароль или им надо админу пароли перепрописать?
Спаибо.
вопрос про PAP и CHAP авторизацию
протокол CHAP сам по себе предусматривает безопасность пересылки информации. Сервер посылает клиенту свое имя и ключ из случайных символов, клиент шифрует ответ , используя пароль и данные, полученные от сервака, а затем посылает ответ серваку вместе со своим именем. в принципе перехватить пароли сложновато, тем более если ты работаешь через VPN... для пользователей, если они были до этого созданы для РАР, то есть зашифрованы, необходимо заново создать пароли админом, НО, не забудь сначала необходимо следовать алгоритму:
>Для авторизации пользователей по протоколу CHAP пароли в базе >должны храниться в формате plain_text.
>Для смены формата необходимо:
>1. Авторизоваться в web интерфейсе администратора.
>2. Прописать в конфигурационном файле /netup/utm/utm.cfg >директиву:
>password_store_method=plain_text
>3. Сменить пароли пользователям. (Alexey Shcherbakov добавлено 2-9-2003 в 21:01)
иначе тебя и под админом не пустит... скажет мол неправильный пароль, юзер... после того как создашь пароли для пользователей в новом формате и они авторизуются , они смогут уже сами менять свои пароли...
>Для авторизации пользователей по протоколу CHAP пароли в базе >должны храниться в формате plain_text.
>Для смены формата необходимо:
>1. Авторизоваться в web интерфейсе администратора.
>2. Прописать в конфигурационном файле /netup/utm/utm.cfg >директиву:
>password_store_method=plain_text
>3. Сменить пароли пользователям. (Alexey Shcherbakov добавлено 2-9-2003 в 21:01)
иначе тебя и под админом не пустит... скажет мол неправильный пароль, юзер... после того как создашь пароли для пользователей в новом формате и они авторизуются , они смогут уже сами менять свои пароли...
Никак. Ибо чтобы добраться до паролей, надо будет поиметь доступ в mysql. Если он открыт только на локальном интерфейсе, то по любому надо будет поиметь root на саму машину. А если уж кто-то поимеет root на комп с биллингом... Тут уж по фиг - шифруются пароли в базе, или нет...Cupitor писал(а):1) А недостаток ли есть когда в базе в открытом виде хранятся пароли или это на безопасность никак не влияет?
Вообще, ИМХО, эту опцию (как и некоторые другие) следовало бы пропИсывать в utm.cfg программой установки - чтобы у людей, которые решат перейти на vpn потом проблем не возникало и лишнего геморроя...
Нет.2) Пользователь по ДиалАпу работал при авторизации PAP при переходе на CHAP ему нужно будет менять настройки соединения?
Давайте-ка подробнее рассмотрим эту тему.
И не забудем упомянуть таблицу collect_plaintext, куда складываются открытые пароли юзеров. И при переходе на plain_text УТМ почему-то забывает о существовании табьлицы users, когда проверяет пароль. Но! При использовании шифрованных паролей, открытый пароль в таблицу collect_plaintext попадает один раз, когда юзер (новый юзер, с т.з. collect_plaintext) авторизуется. Дальнейшая смена пароля пользователем (пользователю) никак не отражается на содержании соответствующей записи в collect_plaintext, и при переходе на открытые пароли, юзер, естессно, ничего кроме "bad autentification" не получит. Мало того. Если пароль имеет более 10 символов (или 8, точно не помню), при шифрованных паролях используются только первые 10 (или
символов, и в базу collect_plaintext попадает только эта вырезка. После перехода на открытые пароли, юзера, имеющие длинные пароли, получают очередной гимор.
Фууу... написал! Всем все понятно?
Проблема перехода остаётся открытой!
И не забудем упомянуть таблицу collect_plaintext, куда складываются открытые пароли юзеров. И при переходе на plain_text УТМ почему-то забывает о существовании табьлицы users, когда проверяет пароль. Но! При использовании шифрованных паролей, открытый пароль в таблицу collect_plaintext попадает один раз, когда юзер (новый юзер, с т.з. collect_plaintext) авторизуется. Дальнейшая смена пароля пользователем (пользователю) никак не отражается на содержании соответствующей записи в collect_plaintext, и при переходе на открытые пароли, юзер, естессно, ничего кроме "bad autentification" не получит. Мало того. Если пароль имеет более 10 символов (или 8, точно не помню), при шифрованных паролях используются только первые 10 (или
символов, и в базу collect_plaintext попадает только эта вырезка. После перехода на открытые пароли, юзера, имеющие длинные пароли, получают очередной гимор.Фууу... написал! Всем все понятно?
Проблема перехода остаётся открытой!
Я чето не особо понял...
Насколько понимаю при смене пароля при переходе на CHAP они должны собраться где-то в открытом виде возможно в той таблице о которой Вы говорите. А проблема то в чем? Они туда не вмещаются или не попадают? в чем проблема с которой Вы столкнулись... чтобы не напороться на грабли?
Насколько понимаю при смене пароля при переходе на CHAP они должны собраться где-то в открытом виде возможно в той таблице о которой Вы говорите. А проблема то в чем? Они туда не вмещаются или не попадают? в чем проблема с которой Вы столкнулись... чтобы не напороться на грабли?