Jump to content
Калькуляторы

Время действия и проверка стойкости паролей.

Добрый день, коллеги.

 

С появлением 3 версии PCI-DSS возникла потребность в изменении политики обработки учеток для доступа к сетевым устройствам.

Наши аудиторы требуют, чтобы осуществлялась проверка стойкости паролей (наличие цифр и букв, длина пароля и т.д)

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

 

Прошу поделиться опытом, реализовывал ли кто-то подобное и как. Из доступных средств у нас есть только бесплатные freeradius и tac_plus,

при этом сеть мультивендорная (в частности cisco и brocade)

Share this post


Link to post
Share on other sites

Мы группируем устройства в NOC и выполняем масс смену паролей время от времени.

 

Остальное рулится радиусом.

Share this post


Link to post
Share on other sites

А какой смысл в разных паролях и смене паролей?

С учетом того, что активное оборудование находится в своем закрытом влане.

А если это оборудование участвует в L3, то на граничных маршрутизаторах закрыт доступ на порты управления.

Edited by vlad11

Share this post


Link to post
Share on other sites

А какой смысл в разных паролях и смене паролей?

Эти требования предписывает новая версия стандарта PCI-DSS(этому стандарту должна соответсвовать сеть, передающая информацию о банковских картах). До этого момента мы не меняли пароли и нас это вполне устраивало.

Share this post


Link to post
Share on other sites

А какой смысл в разных паролях и смене паролей?

С учетом того, что активное оборудование находится в своем закрытом влане.

А если это оборудование участвует в L3, то на граничных маршрутизаторах закрыт доступ на порты управления.

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

По этому мы например используем политики блокировки адреса при ложном срабатывании(не правильно введенном пароле) ну и пароли надлежайшей длинны + только ssh.

проблем пока небыло.

Share this post


Link to post
Share on other sites

А OTP под это правило не подходит?

 

Создавать новый пароль при каждом заходе на циску? Это уже чересчур...

Share this post


Link to post
Share on other sites

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

Бррр.

Делаете несколько разнесенных VPN сервисов/серверов, которые являются точками доступа в управляемый влан(ы).

И все равно вспоминаете, для чего существуют граничные маршрутизаторы.

 

По этому мы например используем политики блокировки адреса при ложном срабатывании(не правильно введенном пароле) ну и пароли надлежайшей длинны + только ssh.

 

Вы себе усложняете жизнь.

Сигнал о неправильном введенном пароле вы получите или через TACACS-сервер или через syslog-сервер.

Да, не все железки умеют ssh.

 

 

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

 

P.S. Да, пароли к железкам очень хорошо вытаскиваются с бэкапов. Охраняйте их тоже!

Edited by vlad11

Share this post


Link to post
Share on other sites

Создавать новый пароль при каждом заходе на циску? Это уже чересчур...

 

Радиус

Share this post


Link to post
Share on other sites

Бррр.

Делаете несколько разнесенных VPN сервисов/серверов, которые являются точками доступа в управляемый влан(ы).

Ну да, при топологии многоуровневая извезда, мне их потребуется внезапно 40 штк. =)) Отличный план.

И все равно вспоминаете, для чего существуют граничные маршрутизаторы.

И этих кстати тоже.

 

 

 

Вы себе усложняете жизнь.

Сигнал о неправильном введенном пароле вы получите или через TACACS-сервер или через syslog-сервер.

Дооо, а это не усложнять. Вводим ещё одну сущность в каждом центре звезды. Это конечно сильно легче чем водрузить анти-брутфорс защиту на железку =)))))

 

Да, не все железки умеют ssh.

 

Вы не умеющие ssh железки на бордеры ставите? Вы нам из начала 90х пишите чтоли? Как там?

Share this post


Link to post
Share on other sites

Радиус

Боже упаси! Только ТАКАКС

почему?

Share this post


Link to post
Share on other sites

В итоге для этой задачи мы выбрали Радиус, потому что наши коммутаторы Brocade напрочь игнорируют некорые сообщения от ТАКАКС сервера и пропускают просроченные учетки. С цисками таких проблем не было.

Всю "логику" проверки сложности пароля реализовали в линуксовых PAM модулях.

Share this post


Link to post
Share on other sites

А у вас radius откуда данные про учётки берёт?

(Попробовали настроить у себя freeradius и учётки в ldap. При использовании rlm_ldap почему-то нормально авторизуется на коммутаторе даже с expired password).

Share this post


Link to post
Share on other sites

А у вас radius откуда данные про учётки берёт?

(Попробовали настроить у себя freeradius и учётки в ldap. При использовании rlm_ldap почему-то нормально авторизуется на коммутаторе даже с expired password).

 

Да, мы тоже заметили такую болезнь во многих модулях freeradius. Модуль PAM в этом случае отрабатывает корректно. Учетки берем из системного /etc/shadow

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this