Запуск процесса на удалённом компьютере – “Проксирование”

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

Чаще всего такие проблемы люди решают с помощью утилит вроде cpau.exe которые создают файл-“ярлык” с зашифрованным паролем административной учетной записи, позволяющий запускать определённую программу. Проблема в том, что хоть пароль и зашифрован, перед запуском программы утилите придётся его расшифровать. А соответственно пользователь может его узнать и использовать для запуска других программ или получения дополнительных привилегий. Практически это конечно достаточно сложно, и тёте Маше из бухгалтерии вряд ли по силам, но вполне возможно.

Чтобы действительно обезопаситься от подобных проблем, но тем не менее разрешить выполнение конкретной команды можно использовать методику которая вроде как называется “проксированием”, а по сути представляет из себя простую реализацию клиент-сервер🙂

Я сегодня опишу простейшую реализацию такой системы, и даже не буду использовать PowerShell, обойдёмся обычным cmd.exe🙂 Нам понадобится 3 командных файла:

Server.cmd

@echo off
set trigger=c:\commandShare\trigger.txt
set action=c:\scripts\action.cmd
set log=c:\scripts\log.txt
:start
if exist %trigger% start %action% & echo %time% %date%>>%log% & del %trigger%
sleep.exe 5
goto start

Action.cmd

for /f "skip=4 tokens=1" %%a in ('net files') do net files %%a /close
exit

Run.cmd

echo test > \\server\commandShare\trigger.txt

Файлы server.cmd и action.cmd находятся на сервере, в папке c:\scripts. Файл Server.cmd запускается при старте системы с административными полномочиями. Этого можно добиться например с помощью планировщика задач (подробнее тут). Он проверяет наличие файла c:\commandShare\trigger.txt и если он существует то:

1) Запускает файл c:\scripts\action.cmd

2) Пишет в c:\scripts\log.txt текущую дату и время

3) Удаляет файл c:\commandShare\trigger.txt.

Затем он ждёт 5 секунд (команду sleep.exe можно взять из Resource Kit или заменить например на ping nonexist -n 1 > nul) и повторяет всё заново.

Файл Action.cmd содержит команды которые будут выполнятся с административными привилегиями, но по инициативе пользователя. В данном случае это отключение открытых по сети файлов.

Ну и как можно догадаться файл Run.cmd находится на рабочем столе пользователя. Единственное что он делает – создает на сетевой папке на сервере файл trigger.txt. Разумеется доступ на запись к этой сетевой папке должен иметь только тот пользователь, который имеет право выполнять вышеприведенную команду.

Метод может и выглядит достаточно сложным, тем не менее является вполне безопасным (разумеется при правильной реализации).

PS: Бонус – server.ps1🙂

$trigger="c:\commandShare\trigger.txt"
$action="c:\scripts\action.cmd"
$log="c:\scripts\log.txt"
while ($true)
{
    if (test-path $trigger) {& $Action; get-date >>$log; del $trigger}
    sleep 5
}

Постарался сделать максимально похожим на cmd версию🙂

Опубликовано в Cmd, PowerShell, Scripting, Tips. 7 комментариев »

комментариев 7 to “Запуск процесса на удалённом компьютере – “Проксирование””

  1. Oleg Medvedev Says:

    Классно.
    В trigger.txt можно команды всякие запихнуть для гибкости.

  2. Xaegr Says:

    2 Oleg Medvedev: Только если потом оооочень осторожно сравнивать эти команды со списком разрешенных команд🙂 Иначе предоставляете пользователю «шелл» с административными правами🙂

    Я постараюсь написать потом более сложную версию на PS, с возможностью задавать список команд и пользователей. Этакий sudo for windows😉

  3. DenisO Says:

    Ну тоесть пароль знать будет не надо, просто меняешь action.cmd и оно само сделает все грязное дело за злоумышленника🙂 А если у юзера не будет прав на изменение этого файла, то зачем его вообще создавать?

  4. Xaegr Says:

    DenisO, разумеется прав на изменение ни на action.cmd ни на server.cmd у пользователя никогда не должно быть. Пользователь имеет возможность лишь создать файл в папке c:\commandShare а в c:\scripts никакого доступа у него нет.
    А разделил я на два файла их просто для удобства отделения самого прокси, от выполняемого кода, который разумеется может быть любым.

  5. Вахитов Андрей Says:

    Разве пользователь может расшифровать пароль, используемый в команде
    runas /savecred /user:Admin@domain «Notepad»?

  6. Xaegr Says:

    2 Вахитов Андрей: Если он может его использовать, то пароль будет расшифровываться на рабочем компьютере пользователя. Возможно для того чтобы его увидеть — придётся обладать правами администратора. Проблема с runas /savecred однако даже не в этом. После того как вы выполните команду
    runas /savecred /user:Admin@domain Notepad
    пользователь выполнит команду
    runas /savecred /user:Admin@domain cmd.exe
    и пароль администратора станет ему уже не очень нужным😉
    http://www.derkeiler.com/Mailing-Lists/NT-Bugtraq/2003-07/0069.html

  7. Вахитов Андрей Says:

    Согласен.


Обсуждение закрыто.

%d такие блоггеры, как: