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