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