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

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

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

 

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

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

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

 

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

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

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

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

Бррр.

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

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

 

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

 

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

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

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

 

 

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

 

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

Edited by vlad11

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

В итоге для этой задачи мы выбрали Радиус, потому что наши коммутаторы 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

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.