Windows 7 скрыть цель * .lnk

808
clargr1

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

Поэтому сейчас я использую psexec, ярлык на рабочем столе с незащищенными именем администратора и паролем. Есть ли способ заблокировать просмотр цели для быстрого доступа? GPO, кажется, не имеет, но есть ли что-нибудь в реестре ??

Лучшее, что у меня пока есть (что плохо), это отключение контекстного меню, чтобы пользователь не мог щелкнуть правой кнопкой мыши (хотя он все еще может использовать Alt + Enter).

Любые мысли были бы великолепны.

2

1 ответ на вопрос

0
Iszi

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

Несколько примеров сценариев:

Пароль указан в параметрах ссылки:

Смешно легко увидеть пароль, посмотрев на свойства ссылки.

Пароль предоставляется через пакетный скрипт, и вы указываете ссылку на скрипт:

Легко найти скрипт по ссылке и найти пароль в скрипте.

Пароль хранится в виде защищенной строки в текстовом файле, который читается и передается в PSEXEC с помощью сценария PowerShell, и вы указываете ссылку на сценарий PowerShell:

Пароль все еще виден в свойствах процесса через диспетчер задач.
(Вид-> Выбрать столбцы-> Командная строка)


Последний вариант выше - от первой редакции ответа Ади Инбара до другого вопроса .

Последняя редакция того же ответ имеет лучшее решение, которое не совсем так тривиально годный для использования, но все еще может получить пароль, если они знают, что они делают. Это определенно не то, что я бы использовал для одной из своих учетных записей или систем, но кажется, что это может предложить приемлемую защиту по вашим стандартам. Решение полностью исключает PSEXEC и выполняет всю работу в PowerShell. Тем не менее, я думаю, что для многопользовательской реализации он все еще требует некоторой работы. (Я не знаю точно, как это сделать сейчас. Обновлю этот ответ, если выясню это позже.) После успешной реализации любой пользователь, имеющий доступ к сценарию и его вспомогательным файлам, все равно может извлечь и расшифровать пароль, но он '


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


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

Пример. Допустим, вы разрешаете мне доступ к вашей системе, и моя учетная запись настроена так, что единственное приложение, которое мне разрешено запускать с повышенными привилегиями, - это Блокнот. Из блокнота я бы ...

  1. File->Open
  2. Установите тип файла «Все файлы ( . )».
  3. Найдите, где я хочу в локальной файловой системе, и запустите / откройте любые файлы / программы, которые я хочу от имени администратора.
    • например: Перейдите C:\Windows\System32\, щелкните правой кнопкой мыши lusrmgr.msc, выберите «Открыть», с помощью MMC, чтобы добавить себя в реальной группе администраторов.
Спасибо за предложение Иззи, я подумал и о вашем втором варианте. Я могу посмотреть на реализацию третьего.
Я также хотел бы использовать [tag: runas] с параметром / savecred, но учетные данные теряются после перезагрузки clargr1 10 лет назад 0
@ clargr1 (RE: RunAs) А затем вы вернулись к хранению учетных данных в виде открытого текста. Серьезно, не делай этого. Особенно для учетной записи домена. Iszi 10 лет назад 0
@ clargr1 Также имейте в виду, что воздействие, упомянутое в третьем варианте, все еще существует во втором - вы можете получить пароль из пакетного сценария * или * из диспетчера задач. Использование сценария PowerShell с объектом SecureString в основном уменьшает подверженность «в сценарии» (понижает ее до уровня последней опции), но все еще оставляет ее открытой для отображения в диспетчере задач. Последний параметр полностью уменьшает воздействие диспетчера задач и делает процесс извлечения из сценария немного более сложным, чем если бы он был открытым текстом. Iszi 10 лет назад 0
Еще раз спасибо @Iszi. Система закрыта, нет доступа в интернет. Идея здесь заключается в появлении защиты (для правил), поскольку все пользователи известны, а компьютер находится в зоне ограниченного доступа. Я попытаюсь реализовать # 3 с заблокированным диспетчером задач / надежным GPO на месте. clargr1 10 лет назад 0
@ clargr1 Вам нужно будет еще немного поработать над # 3 - так же, как это нужно сделать для # 4. Кроме того, та же уязвимость, упомянутая в # 4, все еще будет существовать - пароль - это всего лишь одна строчка PowerShell (не очень простая, но все же) от того, что кто-то имеет доступ к сценарию и его вспомогательным файлам. Iszi 10 лет назад 0