[MaxSmith]

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

 

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

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

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

 

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

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

[myst]

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

 

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

[vlad11]

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

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

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

Изменено 13 марта, 2014 пользователем vlad11

[MaxSmith]

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

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

[myst]

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

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

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

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

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

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

[nuclearcat]

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

 

http://www.qcode.co.uk/pci-dss-requirement-8-part-1-two-factor-authentication/

[MaxSmith]

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

 

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

[vlad11]

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

Бррр.

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

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

 

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

 

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

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

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

 

 

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

 

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

Изменено 14 марта, 2014 пользователем vlad11

[nuclearcat]

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

 

Радиус

[rover-lt]

Радиус

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

[nuclearcat]

http://www.openwall.com/articles/TACACS+-Protocol-Security

[myst]

Бррр.

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

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

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

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

 

 

 

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

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

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

 

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

 

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

[Butch3r]

Радиус

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

почему?

[MaxSmith]

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

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

[OKyHb]

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

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

[MaxSmith]

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

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

 

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