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