MaxSmith Posted March 13, 2014 Posted March 13, 2014 Добрый день, коллеги. С появлением 3 версии PCI-DSS возникла потребность в изменении политики обработки учеток для доступа к сетевым устройствам. Наши аудиторы требуют, чтобы осуществлялась проверка стойкости паролей (наличие цифр и букв, длина пароля и т.д) и было определено его время действия (например, автоматическое "устаревание" пароля каждые 90 дней) со сменой пароля при следующем заходе на устройство. Прошу поделиться опытом, реализовывал ли кто-то подобное и как. Из доступных средств у нас есть только бесплатные freeradius и tac_plus, при этом сеть мультивендорная (в частности cisco и brocade) Вставить ник Quote
myst Posted March 13, 2014 Posted March 13, 2014 Мы группируем устройства в NOC и выполняем масс смену паролей время от времени. Остальное рулится радиусом. Вставить ник Quote
vlad11 Posted March 13, 2014 Posted March 13, 2014 (edited) А какой смысл в разных паролях и смене паролей? С учетом того, что активное оборудование находится в своем закрытом влане. А если это оборудование участвует в L3, то на граничных маршрутизаторах закрыт доступ на порты управления. Edited March 13, 2014 by vlad11 Вставить ник Quote
MaxSmith Posted March 13, 2014 Author Posted March 13, 2014 А какой смысл в разных паролях и смене паролей? Эти требования предписывает новая версия стандарта PCI-DSS(этому стандарту должна соответсвовать сеть, передающая информацию о банковских картах). До этого момента мы не меняли пароли и нас это вполне устраивало. Вставить ник Quote
myst Posted March 13, 2014 Posted March 13, 2014 А какой смысл в разных паролях и смене паролей? С учетом того, что активное оборудование находится в своем закрытом влане. А если это оборудование участвует в L3, то на граничных маршрутизаторах закрыт доступ на порты управления. Всякое бывает, особенно когда у тебя сеть л3, оборудование размазано по стране и точки входа заранее не известны. По этому мы например используем политики блокировки адреса при ложном срабатывании(не правильно введенном пароле) ну и пароли надлежайшей длинны + только ssh. проблем пока небыло. Вставить ник Quote
nuclearcat Posted March 13, 2014 Posted March 13, 2014 А OTP под это правило не подходит? http://www.qcode.co.uk/pci-dss-requirement-8-part-1-two-factor-authentication/ Вставить ник Quote
MaxSmith Posted March 14, 2014 Author Posted March 14, 2014 А OTP под это правило не подходит? Создавать новый пароль при каждом заходе на циску? Это уже чересчур... Вставить ник Quote
vlad11 Posted March 14, 2014 Posted March 14, 2014 (edited) Всякое бывает, особенно когда у тебя сеть л3, оборудование размазано по стране и точки входа заранее не известны. Бррр. Делаете несколько разнесенных VPN сервисов/серверов, которые являются точками доступа в управляемый влан(ы). И все равно вспоминаете, для чего существуют граничные маршрутизаторы. По этому мы например используем политики блокировки адреса при ложном срабатывании(не правильно введенном пароле) ну и пароли надлежайшей длинны + только ssh. Вы себе усложняете жизнь. Сигнал о неправильном введенном пароле вы получите или через TACACS-сервер или через syslog-сервер. Да, не все железки умеют ssh. После создания жестких политик, вторичные политики - длина, стойкость и время действия будут для галочки проверяющих. P.S. Да, пароли к железкам очень хорошо вытаскиваются с бэкапов. Охраняйте их тоже! Edited March 14, 2014 by vlad11 Вставить ник Quote
nuclearcat Posted March 14, 2014 Posted March 14, 2014 Создавать новый пароль при каждом заходе на циску? Это уже чересчур... Радиус Вставить ник Quote
rover-lt Posted March 14, 2014 Posted March 14, 2014 Радиус Боже упаси! Только ТАКАКС Вставить ник Quote
nuclearcat Posted March 15, 2014 Posted March 15, 2014 http://www.openwall.com/articles/TACACS+-Protocol-Security Вставить ник Quote
myst Posted March 16, 2014 Posted March 16, 2014 Бррр. Делаете несколько разнесенных VPN сервисов/серверов, которые являются точками доступа в управляемый влан(ы). Ну да, при топологии многоуровневая извезда, мне их потребуется внезапно 40 штк. =)) Отличный план. И все равно вспоминаете, для чего существуют граничные маршрутизаторы. И этих кстати тоже. Вы себе усложняете жизнь. Сигнал о неправильном введенном пароле вы получите или через TACACS-сервер или через syslog-сервер. Дооо, а это не усложнять. Вводим ещё одну сущность в каждом центре звезды. Это конечно сильно легче чем водрузить анти-брутфорс защиту на железку =))))) Да, не все железки умеют ssh. Вы не умеющие ssh железки на бордеры ставите? Вы нам из начала 90х пишите чтоли? Как там? Вставить ник Quote
Butch3r Posted March 16, 2014 Posted March 16, 2014 Радиус Боже упаси! Только ТАКАКС почему? Вставить ник Quote
MaxSmith Posted March 17, 2014 Author Posted March 17, 2014 В итоге для этой задачи мы выбрали Радиус, потому что наши коммутаторы Brocade напрочь игнорируют некорые сообщения от ТАКАКС сервера и пропускают просроченные учетки. С цисками таких проблем не было. Всю "логику" проверки сложности пароля реализовали в линуксовых PAM модулях. Вставить ник Quote
OKyHb Posted March 17, 2014 Posted March 17, 2014 А у вас radius откуда данные про учётки берёт? (Попробовали настроить у себя freeradius и учётки в ldap. При использовании rlm_ldap почему-то нормально авторизуется на коммутаторе даже с expired password). Вставить ник Quote
MaxSmith Posted March 17, 2014 Author Posted March 17, 2014 А у вас radius откуда данные про учётки берёт? (Попробовали настроить у себя freeradius и учётки в ldap. При использовании rlm_ldap почему-то нормально авторизуется на коммутаторе даже с expired password). Да, мы тоже заметили такую болезнь во многих модулях freeradius. Модуль PAM в этом случае отрабатывает корректно. Учетки берем из системного /etc/shadow Вставить ник Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.