Назад | Перейти на главную страницу

Вы используете один и тот же пароль root для всех устройств?

Это как бы связано с Рекомендации по использованию паролей но конкретнее.

Вы используете один и тот же пароль root для всех серверов в вашей организации? Для класса устройств?

Я хочу сказать «да, везде», но в некоторых случаях все равно «нет». Моя компания использует Сейф с паролем управлять паролями для наших клиентов, создавая «сейфы» для каждого клиента. У многих клиентов есть уникальные случайно назначаемые пароли для root, локального администратора, устройств и т. Д. К сожалению, некоторые (либо из-за работы, проделанной предыдущими поставщиками, либо из-за нашей лени) могут использовать один и тот же пароль на нескольких устройствах или на нескольких серверные компьютеры.

Для моих личных паролей я решил перейти на такую ​​утилиту, как Создатель паролей, который принимает «главную кодовую фразу» и некоторые другие факты (имя веб-сайта, имя пользователя и т. д.) и создает случайный пароль из безопасной хеш-функции. Если вы знаете свой «мастер-пароль» и «другой факт», вы можете использовать программное обеспечение для повторной смены пароля каждый раз, когда он вам понадобится (т.е. пароль никогда нигде не сохраняется, в зашифрованном виде, в виде открытого текста или иным образом).

Мне еще предстоит найти корпоративный инструмент для хранения паролей, который делает все, что я хочу:

  • Доступ на основе SSL из браузеров в качестве пользовательского интерфейса
  • Аутентификация LDAP, разрешения на доступ к паролям в базе данных на основе членства в группе LDAP.
  • Ведение журнала аудита паролей, к которым имеет доступ каждый пользователь (так что я знаю, что менять, когда кто-то уходит из компании).
  • Настраиваемые уведомления об истечении срока действия пароля в зависимости от пользователя (например, «Срок действия каждого пароля, который« Боб »когда-либо использовал с тех пор, как мы его уволили»), на основе даты последней установки пароля или количества уникальных пользователей, которые получили доступ к паролю (« Вся служба поддержки, ИТ-отдел и обслуживающий персонал получили доступ к этому паролю - срок его действия истек. ")
  • Метаданные для каждого пароля, включая сторону для уведомления по электронной почте в случае истечения срока действия, дату создания, дату последнего изменения, примечания.
  • Дополнительная система подключаемых модулей, позволяющая самой системе паролей подключаться к системам и автоматически обновлять просроченные пароли.
  • В идеале работает на веб-сервере под управлением Windows или Linux, возможно, с использованием sqlite в качестве серверной части.

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

Я использую ключи SSH, использую один и тот же для всех серверов и сохраняю надежный пароль для своего ключевого файла. Избавляет от обострения.

Для устройств, где это не сработает, я бы использовал пароль с трудно угадываемым ядром, а затем использовал DNS-имя устройства, IP-адрес или другую общую характеристику (например, ОС или бренд), чтобы сделать пароль уникальный для устройства. Это особенно хорошо сработало для групп похожих устройств. Просто сохраните в секрете шаблон / мнемонику вместе с ядром, и у вас будет сложный уникальный пароль, который легко запомнить.

разные пароли для каждой машины, но мы храним их в pwsafe. PITA, чтобы посмотреть вверх, но не дает нам взломать одну брешь.

Нет никогда. Что я делаю, чтобы помочь мнемонике, так это иметь длинный (12 символов или около того) общий префикс, который изменяется атрибутом средней длины (6 символов) каждого сервера, если они находятся в одной стойке (или как вы считаете, группа серверов , который должен определяться исходя из потребности в доступе (см. комментарий Эрни и мой ответ)).

Например, если группа серверов состоит из mercury (10.0.1.1, smtp), mars (10.0.1.2, firewall), bacchus (10.0.1.3, web), а общий префикс - R %% SDO23jfida, то

- mercury: R%%SDO23jfida11001mersmtp
- mars: R%%SDO23jfida21001marfirewall
- bacchus: R%%SDO23jfida31001bacweb

Тот, который использовался в организации, где я работал:

Пароль администратора рабочего стола / локального ПК одинаков (но, поскольку мы создаем фантомы на всех наших машинах, это единственный способ сделать это, и если кто-нибудь когда-нибудь найдет этот пароль, мы все равно сможем изменить наш исходный образ-призрак и обновить все машины, чтобы получить новое изображение, и все будет в порядке.

У каждого сервера свой пароль. Опять же, мы не имеем дело с слишком большим количеством серверов, если я правильно помню, около 6, к которым у меня был доступ (но я уверен, что у нас было больше), и вместо того, чтобы делать слишком сложный пароль, они выбрали простой, легко запоминающийся пароль, добавив к ним разумный | eet5peak и сделав их очень длинными (но опять же, легко запоминающимися) :)

Лично я считаю, что для настольных ПК вы хотите сохранить одинаковый пароль root / admin, чтобы упростить управление с помощью локальной учетной записи администратора.

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

Мой 5c

Мы везде используем один и тот же пароль root, хотя он соответствует лучшим практикам (на самом деле, генерируется случайным образом). Это необходимо только в том случае, если нам нужно физически захватить машину, например, для проверки файловой системы или криминалистической экспертизы после компрометации. Как и Джефф, ssh - единственный протокол удаленного доступа, и он отключен для пользователя root.

Мы используем случайно сгенерированный длинный пароль с задержкой для каждого ящика и никогда его нигде не сохраняем. обычная авторизация пользователя управляется через LDAP, как и Sudoers, поэтому пароль нам КОГДА-ЛИБО нужен только тогда, когда сетевой доступ не работает, и в этом случае вполне допустимо просто отключить сервер и перейти в однопользовательский режим, исправить конфигурацию сети , и верните его обратно.

ртуть: R %% SDO23jfida11001mersmtp
Марс: R %% SDO23jfida21001marfirewall
bacchus: R %% SDO23jfida31001bacw

myc0mm0npa $$ w0rd.105
myc0mm0npa $$ w0rd.web

Я видел, как многие люди поступали так, но никто не мог объяснить, что это безопаснее, чем использование одного и того же пароля. Что мешает любому, кто видит один из паролей, узнать остальные? Единственное преимущество - разные хеши, но разные соли на разных машинах тоже решают эту проблему.

Может кто-нибудь просветить меня по этому поводу?

Учитывая, что пароль - это последний линия защиты, я бы сказал, что это уже не так важно, как было раньше.

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

Наша политика паролей состоит в том, чтобы использовать общий префикс, который трудно угадать, а затем использовать общий пароль для каждого класса серверов. Это уменьшает количество паролей, которые я должен запомнить, защищая другие серверы от «ошибок». Однако, в отличие от Vinko, мы не используем никаких систем, которые объединяют что-либо, связанное с машиной. Я бы не рекомендовал этого делать, поскольку, как только кто-либо в организации получает доступ к одному паролю (потому что он им нужен), они могут довольно легко вычислить другие пароли.

Я регистрирую все входы root и позволяю фильтру ошибок (в моем случае logcheck) передавать их на мою электронную почту, чтобы я знал, когда кто-то пытается взломать пароль root. Ограничения на то, откуда это можно сделать, убедитесь, что моя электронная почта не переполнена этими журналами.

Я заметил, что никто не говорит о частой смене паролей. Да, это боль ... где-то, но рано или поздно любой пароль просочится (кто-нибудь уйдет?). Я думаю, что любой пароль должен может быть изменен через некоторое время, независимо от того, что вы обычно используете для его создания. Наша политика - каждый год угадывать абсолютно случайный пароль, а затем постепенно менять его на наших устройствах. По иронии судьбы постепенное изменение позволило нам получить немного больше безопасности, поскольку в любой момент времени мы не везде одинаковый пароль ( не хорошая вещь).

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

myc0mm0npa$$w0rd.105
myc0mm0npa$$w0rd.web

Но все же небезопасно. Что я сейчас делаю, так это сгенерировал разные корневые пароли для каждого сервера или устройства.

Я удивлен, что никто об этом еще не упомянул, но я бы использовал ldap с kerberos, чтобы создать единый логин, который будет использовать SSH-ключи для определенных устройств. Это, конечно, предполагает, что устройства, к которым я пытаюсь подключиться, поддерживают аутентификацию LDAP. С помощью LDAP я могу создавать группы пользователей, у которых есть доступ к определенным устройствам. Кроме того, все мои пользователи входят в систему через централизованный сервер Kerberos, поэтому вход в систему может происходить только локально, и я могу немедленно отозвать учетную запись, если она по какой-то причине будет взломана.

Если у вас есть пароли или ключи на более чем 100 машинах, получайте удовольствие, изменяя все эти пароли или файлы authorized_keys. Мне не о чем беспокоиться.

Использование одного и того же пароля root для нескольких учетных записей или устройств - плохая идея. Этого никогда не будет в ИТ-аудите, поскольку нет подотчетности. Как только кто-то получит пароль, он сможет получить доступ к нескольким учетным записям, и вы не сможете доказать, кто что-то сделал или не сделал. Я иногда видел, как люди пытались привлечь к ответственности посредством регистрации IP-адресов, но это обременительно и легко взломать.

Чтобы обеспечить подотчетность и пройти SOX, PCI, HIPAA и т. Д., Вам необходимо ограничить доступ к общим учетным записям для одного человека за раз, отслеживать, к чему затем осуществляется доступ, а затем менять пароль, когда они будут выполнены.