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

Если Вы часто переустанавливаете по любой причине, могло бы быть полезно написать сценарий всех этих настроек. Каждая установка, которая хранится в реестре, может быть установлена с командой "reg" в *.cmd сценарии. Можно использовать Google для нахождения большого количества настроек. Необходимо будет найти некоторых сами, все же. Загрузите ProcMon с Sysinternals по www.sysinternals.com. Используйте его для контроля реестра, в то время как Вы изменяете желаемые настройки в Панели управления или везде, где. Затем запишите сценарий с помощью "reg" для управления той установкой.

6
задан 13 April 2017 в 15:14
13 ответов

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

Для моих личных паролей я стал интересующимся перемещением в утилиту как Passwordmaker, который берет "основной пароль" и некоторый другой факт (название веб-сайта, имя пользователя, и т.д.) и создает случайный пароль из безопасной хеш-функции. Пока Вы знаете свой "основной пароль" и "другой факт", можно использовать программное обеспечение для regerate пароль каждый раз, когда Вам нужен он (т.е. пароль никогда не хранится нигде, шифруется, простой текст, или иначе).

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

  • Основанный на SSL доступ от браузеров как UI
  • Аутентификация LDAP, полномочия к паролям доступа в базе данных на основе состава группы LDAP.
  • Поддерживает журнал аудита паролей, к которым получает доступ каждый пользователь (таким образом, я знаю, что измениться, когда кто-то покидает компанию).
  • Уведомления Configuratable для истечения пароля на основе пользователя (т.е. "Истекают каждый пароль, который когда-либо использовал 'боб', так как мы увольняем его"), на основе пароля даты в последний раз набор, или на основе числа уникальных пользователей, которые получили доступ к паролю ("Целая справочная служба, отдел ИТ и вспомогательный штат получили доступ к этому паролю - истекают он".)
  • Метаданные по каждому паролю включая сторону для уведомления по электронной почте в случае истечения, даты создания, длятся измененную дату, примечания.
  • Дополнительная сменная система, чтобы позволить самой системе пароля соединяться с системами и обновлением истекла пароли автоматически.
  • Идеально работает на Windows или основанном на Linux веб-сервере, вероятно, с помощью sqlite как бэкенд.

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

8
ответ дан 3 December 2019 в 00:01

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

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

3
ответ дан 3 December 2019 в 00:01

другой пароль для каждой машины, но мы сохраняем их всех в pwsafe. ЛАВАШ для поиска, но мешает одному нарушению иметь нас pwnd.

2
ответ дан 3 December 2019 в 00:01
  • 1
    +1 Это - способ, которым мы делаем это, также. –  Bill B 14 July 2009 в 04:43

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

Например, если группа серверов составлена ртутью (10.0.1.1, smtp), Марс (10.0.1.2, брандмауэр), Вакх (10.0.1.3, сеть), и общий префикс является R %% SDO23jfida, то

- mercury: R%%SDO23jfida11001mersmtp
- mars: R%%SDO23jfida21001marfirewall
- bacchus: R%%SDO23jfida31001bacweb
2
ответ дан 3 December 2019 в 00:01
  • 1
    +1 для хорошей идеи. Победите меня к нему.:) –  Geoff Fritz 13 July 2009 в 22:03
  • 2
    - 1 для плохой идеи. Если кто-то в компании требует доступа к одной машине, но не всех других, it' s не трудный для того человека выяснить остальную часть паролей. Если you' ре единственный, кому когда-либо был бы нужен доступ (Вы и Ваш босс, по крайней мере), в этом случае больше питания Вам. –  Ernie 13 July 2009 в 22:44
  • 3
    That' s, почему определение " группа servers" релевантно. Если кто-то в компании мог бы потребовать доступа к одной машине, но не всех других, то те серверы не формируют группу. Необходимо изменить префикс на группу также. –  Vinko Vrsalovic 13 July 2009 в 22:53
  • 4
    Причина я думаю, что это - плохая идея, состоит в том, потому что суффикс связан с названием машины и его целью. Если бы у меня только был доступ к группе Марса, то я мог легко предположить, что суффикс для Меркурия 11001mersmtp, потому что я знаю то, на что похож обратный адрес DNS. –  Ernie 13 July 2009 в 23:40
  • 5
    Точка должна определить группу согласно потребностям. Если можно предвидеть ту потребность, можно a) изменить префикс на группу и b) изменить способ здания суффикса на группу –  Vinko Vrsalovic 14 July 2009 в 00:18

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

1
ответ дан 3 December 2019 в 00:01

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

1
ответ дан 3 December 2019 в 00:01
  • 1
    Итак, почему не только отключают пароль root в целом? Я полагал просто, что также, и единственная ситуация, что спасательный диск/отдельный пользователь не мог обработать, имела место, когда я хотел сделать судебную экспертизу на поставленной под угрозу машине. Перезагрузка очистила бы список процессов, который мог бы иметь ценное доказательство. –  Chad Huneycutt 14 July 2009 в 03:50

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

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

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

Лично я верю для настольных ПК, Вы хотите сохранить корень / пароль администратора то же удостоверяющееся легкое управление с помощью Локальной Администраторской Учетной записи.

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

Мой 5c

2
ответ дан 3 December 2019 в 00:01

ртуть: R %% SDO23jfida11001mersmtp
Марс: R %% SDO23jfida21001marfirewall
Вакх: R %% SDO23jfida31001bacw

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

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

Кто-то может просветить меня на этом?

0
ответ дан 3 December 2019 в 00:01
  • 1
    I' m виновный в плохих примерах, но не в плохих комментариях. Я действительно имею в виду это it' s не легко отгадываемый, если Вы вне секрета. Можно даже считать основной пароль из листка бумаги, но Вас won' t легко предполагают переменную часть, если Вы не в секрет. та точка является, конечно, тем же наличием того же пароля, но идея, защищают его от людей, которые являются вне секрета и овладевают основным паролем. Можно изменить префикс и способ генерировать суффикс. На самом деле, it' s тот же основной принцип использование Passwordmaker, процитированное в текущем главном ответе. –  Vinko Vrsalovic 14 July 2009 в 00:44

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

Однако последней вещью, в которой Вы нуждаетесь, является некоторый Yahoo в Вашем бывшем вне себя офисе, который намного более распространен.

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

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

0
ответ дан 3 December 2019 в 00:01
  • 1
    Вы просто изменяете один набор проблем для другого. Что, если человек должен получить доступ только к одному серверу всех серверов класса? Я предпочитаю уникальный пароль на машину, чем уникальный пароль на группу машин –  Vinko Vrsalovic 13 July 2009 в 22:56
  • 2
    Затем политика может измениться, должен та возможность возникать. Прямо сейчас это doesn' t вопрос. Единственный пароль root, который любой знает, но меня и босса находится в классе машины одного. Но я несомненно не использую ничего даже неопределенно связанного с функцией машины или ее IP для уникального бита пароля. –  Ernie 13 July 2009 в 23:33
  • 3
    Точно, см. мой комментарий выше, политика может и ДОЛЖНА измениться согласно потребностям. Нет ничего внутренне худшего при наличии суффикса на основе характеристики машины, чем фиксация его. Машины имеют много характеристик, которые могут быть указаны различными и переменными способами –  Vinko Vrsalovic 14 July 2009 в 00:19

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

0
ответ дан 3 December 2019 в 00:01

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

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

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

0
ответ дан 3 December 2019 в 00:01
  • 1
    целый вторая часть не является легко отгадываемой (т.е., просто IP-адрес) затем, это небезопасно, но можно легко сделать вещи более сложными для создания этого разумным безопасным паролем), –  Vinko Vrsalovic 13 July 2009 в 22:39
  • 2
    Нет, идея для него, чтобы не быть очевидной –  Vinko Vrsalovic 14 July 2009 в 00:35
  • 3
    В самом деле...? " целый вторая часть не является легко отгадываемой [..] затем это - insecure" . I' d говорят, удаляют " not" или замена " insecure" с " secure"... :-) –  Arjan 14 July 2009 в 00:41
  • 4
    Heh, право. Замена, небезопасная для безопасного!:) –  Vinko Vrsalovic 14 July 2009 в 01:26

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

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

0
ответ дан 3 December 2019 в 00:01
  • 1
    Да, существует LDAP и Kerberos, и они работают отлично для регулярного использования. Что относительно устройств это don' t поддерживают их? Что относительно того, когда необходимо сделать обслуживание на сервере офлайн, когда LDAP и Kerberos являются not' t доступный? Вам все еще нужны пароли для тех случаев. –  Kamil Kisiel 14 July 2009 в 02:46

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

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

0
ответ дан 3 December 2019 в 00:01

Теги

Похожие вопросы