Varonis Systems corporate blog
Information Security
System administration
PowerShell
Comments 13
-2

В моей практике имеется курьезный случай, когда сотрудники информационной безопасности "продавили" принудительную установку PS последней версии на все серверы (2008 R2) и рабочие станции (7), мотивируя это в том числе и наличием "расширенного аудита командной строки" powershell. В то время мои администраторы легко обходились без PS, но инфобезы не могли воплотить в жизнь результаты очередного своего курса повышения квалификации. Вопрос — зачем в инфраструктуре разворачивать возможный backdoor — остался без вразумительного ответа. Вот такой вот насильственный прогресс.

+2
И в 2008R2 и уж тем более в 7, powershell стоит по умолчанию, так что по вашей логике бэкдор уже есть. А наличие аудита введенных команд и скриптов это азбука ИБ.
0

Версия PS из коробки (2, если не ошибаюсь) в WS2008R2/7 как раз и не позволяла делать все эти веселые трюки, описанные в статье. Поправьте меня, если ошибаюсь.

+4
v2 без проблем использует весь арсенал .NET, VBscipt, Wscript, WMI и т.д., а там уже дело техники т.е. все веселье доступно и в ней.
0
2008R2 действительно шёл с PS version 2, только его поддержка заканчивается уже в январе 2020 года и в связи с этим в корпоративном сегменте использоваться, скорее всего, больше не будет.
0
И правильно говорили — действительно для аудита безопасности — полезная штука. Особенно, если журналы в он-лайн режиме выгружать.
0
повершелл мне нравится, особенно тем что в C# прогу можно интегрировать Powershell и наоборот. Что на Powershell можно реализовать полноценный GUI на Winforms или WPF и тогда для юзера вообще не видно разницы между C# .exe и .PS1
Я конечно не спец, но вообще так можно подумать, что это повершелл виноват в том, что юзер может что-то случайно скачать и запустить из интернета. И вообще то, что не остаются на диске файлы начального загрузчика, ничего принципиально не меняет. Если уж юзер каким-то образом был спровоцирован что-то скачать и запустить, то запрет повершелла или других скриптовых языков никак не помешает зловреду поселиться в системе и собирать доступные данные из AD/LDAP.
Вот отсутствие админских прав у юзера сильно мешает дальнейшей атаке на сеть. Остается ждать админских прав. А настоящее счастье будет если после получения админских прав на компе, залогинится чел с правами на сервера или даже на домен. Вот ограничение юзерских прав, разделение юзерских и админских аккаунтов, чтобы использовать юзерские аккаунты для работы на юзерских компах, а админских аккаунтов для работы на серверах и ни в коем случае на юзерском компе, может дать больший эффект для защиты конторы.
0

К сожалению, для Applocker требуется Windows Enterprise, а SRP очень сложно правильно настроить без ложных срабатываний. Ситуация усугубляется невозможностью рекурсивных правил по маске с работой обычных правил по пути к папке.

0
get-ChildItem | ? {$_.length –gt 10000000 | % {write-host$_.length $_.name -separator "`t`t"}


Не хватает пробела и "}" :-)
0
Да и вообще по «канонам» лучше не сокращать так адово все.

Get-ChildItem -Path | Where-Object -FilterScript {$_.Length –gt 10000000} | ForEach-Object -Process {Write-Host $_.Length $_.Name -Separator "`t`t"}


Также удобнее. :)
Only those users with full accounts are able to leave comments., please.