Tag Archives: Windows

Новые технологии ломают интернет. Часть 2.

Это вторая часть. Первая часть.

1. DNS-over-HTTPS (DoH) и split-horizon

DNS используется для разрешения имени сайта в IP адрес. Некоторые сайты могут быть доступны только внутри сети. Когда DNS сервер отвечает по-разному в зависимости откуда пришел запрос —
это называется расщепленный горизонт (split horizon).

Пример.

  • Локальный DNS сервер для домена example.org
  • DNS сервер при запросе из интернета записи www.example.org отвечает 1.2.3.4
  • DNS сервер при запросе из локальной сети записи www.example.org отвечает 10.20.30.40
  • DNS сервер при запросе только из локальной сети записи pii.example.org будет отвечать

Изначально DNS сервер для разрешения имен указывается в настройках сетевого интерфейса. Запрос к нему отправляется открытым текстом на порт 53.

Проверка какой DNS сервер установлен на интерфейсе

ipconfig /all

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

Однако DNS over HTTPS (DoH) ломает эту последовательность. DoH забирает настройку DNS сервера с уровня сети и перекладывает ее на уровень приложения (веб-браузера). Количество провайдеров DoH невелико. А в некоторых браузерах вшит список DoH серверов, который нельзя поменять.

Таким образом DNS сервер третьей стороны получает доступ ко всему списку сайтов, которые клиент запрашивает. DNS запрос инкапсулируется в HTTPS. Затем зашифрованный запрос отправляется на сторонний DoH сервер на порт 443.

Пример.

  1. Веб браузер использует DoH
  2. Пользователь вводит адрес сайта pii.example.org
  3. DNS запрос уходит на DoH сервер в Интернете вместо локального DNS сервера
  4. Третья сторона получает информацию о запрошенном сайте. И это проблема

Для работы DoH нужно чтобы веб браузер и DNS сервер поддерживали DoH.

Вывод.

  • Все плохо. Существуют политики безопасности, но каждый веб браузер теперь сам решает как работать с DNS
  • Тех. поддержка DNS становиться более затратной. Появляется еще одна точка отказа
  • В корпоративной сети повышается риск утечки информации
  • DoH ломает captive portals. Их используют при аутентификации в корпоративной сети
  • DoH снижает пользу nslookup. Информация из nslookup перестает совпадать с информацией, получаемой веб браузером
  • DoH работает на HTTP/2. О нем в предыдущей части

Проверка записи через DoH

curl -H "Content-Type: application/dns-json" "https://dns.google.com/resolve?name=www.google.com&type=A"

Пример выше использует JSON формат. В DoH также используется бинарных формат (wireformat). Каждый DoH сервер решает сам, какой формат использовать.

В новых версиях Windows 10 появится DoH клиент. И будет включен по умолчанию.

Проверить работу DoH можно через захват пакетов. Запустив поиск по 53 порту. Если на нем нет трафика, а имена разрешаются, значит DoH работает.

Захват пакетов на Windows 10 с помощью новой утилиты захвата пакетов

pktmon filter remove
pktmon filter add -p 53
pktmon start --etw -m real-time
pktmon stop

eSNI в Firefox. Напрямую это с DoH не связано, но может поломать SNI прокси из прошлой части. Напомню, SNI является адресом сайта, который клиент передает веб серверу открытым текстом. Включение шифрования SNI в TLS

about:config
network.trr.uri — mozilla.cloudflare-dns.com/dns-query
network.security.esni.enabled true
network.trr.mode 2
network.trr.bootstrapAddress 1.0.0.1

Комбинируя DoH и eSNI можно защититься от прослушки. DoH будет шифровать запрос адреса сайта у DNS сервера. eSNI будет шифровать запрос сайта у веб сервера. В компаниях это обходиться путем принудительной установки доверенного сертификата прокси сервера. Прокси сервер пропускает через себя весь веб трафик клиентов. Он выпускает сертификаты для всех запрашиваемых сотрудниками HTTPS сайтов и осуществляет расшифровку передаваемого трафика.

Источник 1
Источник 2
Источник 3
Источник 4
Источник 5
Источник 6
Источник 7
Источник 8
Источник 9
Источник 10
Источник 11
Источник 12
Источник 13
Источник 14
Источник 15
Источник 16
Источник 17
Источник 18
Источник 19
Источник 20

2. HSTS enforcing ssl и .dev домен

OK с этим я сам не сталкивался. Но для веб разработчиков было сюрпризом.

С помощью HSTS веб сервер может указать клиенту подключаться по HTTPS.

Пример.

  • Веб сервер настроен отправлять специальный заголовок
  • Веб бразуер подключается к веб серверу
  • Веб сервер посылает специальный HTTP заголовок Strict-Transport-Security
  • Этот заголовок передается только через защищенное HTTPS соединение
  • Этот заголовок изменяет поведение браузера с доменом и опционально поддоменом
  • При первом корректном соединении HTTPS браузер получает HSTS заголовок и сохраняет правило на указанный период
  • Если сертификат на HTTPS некорректный, на сервере с ключенным HSTS, то веб браузер запрещает пользователю заходить на сайт

Пример заоголовка Strict-Transport-Security

max-age=63072000; - время кэша браузера
includeSubDomains; - применять политику на поддомены
preload - использовать список обязательного HTTPS (см. ниже)

Почему это проблема:

  • При запросе HTTP:\\www.example.org пользователь ожидает подключение по HTTP протоколу. При HSTS браузер кэширует политику и принудительно переключает коммуникацию на HTTPS. Т.е. самый первый запрос будет идти сразу по HTTPS не смотря на явно указанный протокол HTTP
  • Использование HSTS preload list. В браузер вшит список доменов обязательных для загрузки по HTTPS. Т.е в браузер захардкожены правила, которые невозможно поменять. Имея доступ к веб серверу на определенном домене, можно запросить включение в статический список HSTS для сайта и всех поддоменов.
  • Запрет на подключение с некорректным сертификатом. Изначально, если сайт по HTTPS выдает ошибку неправильного сертификата, то пользователь может продолжить подключение на свой риск. Есть соответствующая кнопка. Веб сервер сайта (и опционально поддомены) с HSTS явно запрещают пользователю подключаться к сайту с проблемным сертификатом. Нет кнопки продолжить, подключиться к сайту невозможно. И это проблема

Пример с DEV доменом.

  • При локальной разработке используются «непубличные» домены
  • Их прописывают в локальный hosts файл на машине разработчика
  • Почти любой домен может стать публичным (список запрещенных доменов ограничен)
  • Это произошло с .DEV доменом. Google купил этот домен
  • Google установил политику HSTS на домен и его поддомены
  • Локальный сайт разработчика test.dev перестал работать
  • В браузере вшито требование использовать однозначно HTTPS ко всем сайтам домена DEV и поддоменов
  • Работа разработчика нарушена

Небольшое отклонение: для защиты от поддельных сертификатов еще используется механизм Certificate Transparency. Его суть в том, что о всех выпускаемых сертификатах CA записывает информацию в публичный лог. Браузер подключаясь к HTTPS сайту, проверяет лог по отметке SCT и если не находит в нем сертификата, значит он поддельный. Специальная отметка может передаваться в заголовке веб севреа или в самом сертификате. Как же работает расшифровка TLS трафика в компаниях? Или при самоподписанных сертификатах (self-signed)? Прокси сервер использует сертификат внутреннего центра сертификации (иначе кто бы ему разрешил выдавать сертификаты на все сайты интернета). А Certificate Transparency работает только для публичных CA.

Проблема с сертифкатом и всей системой PKI в том, что любой центр сертификации (CA) может выдать сертификат к любому сайту.

Вывод..

  • Все плохо

Источник 1
Источник 2
Источник 3
Источник 4
Источник 5
Источник 6
Источник 7
Источник 8
Источник 9
Источник 10
Источник 11
Источник 12
Источник 13
Источник 14
Источник 15
Источник 16
Источник 17
Источник 18
Источник 19
Источник 20
Источник 21
Источник 22
Источник 23
Источник 24

3. Windows Fast Boot и системные драйверы

ОК это не про Интернет, но тоже не работает.

При изменении системных настроек (например установка драйвера) требуется полный перезапуск компьютера. Перезапустив систему новые настройки включаются.
В новой версии Windows 10 выключение компьютера было заменено на гибридный сон. При этом название операции — выключить компьютер — осталось.

Пример.

  1. Устанавить драйвер
  2. Требуется перезагрузка
  3. Компьюетр перезагружается
  4. После перезагрузки драйвер не работает
  5. Потому что новые настройки не применяются. Потому что для них нужно полное выключение, а его не происходит.

Вывод.

  • Отключить Windows Fast Boot. Это чуть увеличит скорость запуска системы. Но поможет избежать ошибок с применением системных настроек.

Чтобы в Windows 10 отключить Быстрый запуск

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Power" /f /v HiberbootEnabled /t REG_DWORD /d 0

Источник 1

Новые технологии ломают интернет. Часть 1.

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

Спиритуальное продолжение этого поста

1. SPF, DKIM не работают без DMARC.

ОК, здесь все работает, только обязательно связке.

Для защиты от спама используются следующие DNS записи:

  • SPF— указывает какой сервер может отправлять почту с домена. Защищает поле MAIL FROM. Это поле передается в SMTP сессии и не видно почтовому клиенту.
  • DKIM — указывает публичный ключ. Защищает поле FROM. Это поле передается в теле письма и видно почтовому клиенту.

Проблема в том, что SPF и DKIM не работают без DMARC.

Пример.

  1. Злоумышленник регистрирует DNS домен fake-bank.org
  2. Злоумышленник создает в домене записи:
    • A — mail.fake-bank.org IN 1.1.1.1
    • MX — mail.fake-bank.org
    • SPF — v=spf1 mx ip4:1.1.1.1 -all. Публикуется в корне fake-bank.org.
    • DKIM — v=dkim1;p=pubkey. Публикуется в поддомене selector._domainkey.fake-bank.org.
  3. Злоумышленник шлет подделанное письмо жертве притворяясь настоящим банком
  4. Почтовый сервер получает письмо от злоумышленника
    MAIL FROM: fraud@fake-bank.org - RFC5321.MailFrom
    FROM: manager@bank.org - RFC5322.From
    DKIM: d=fake-bank.org
  5. Почтовый сервер проверяет MX запись. Письмо было отправлено с сервера mail.fake-bank.org. Который отвечает за отправку писем в домене.
  6. Почтовый сервер проверяет SPF запись. Письмо было отправлено с домена fake-bank.org. Который разрешает отправку писем севером mail.fake-bank.org
  7. Почтовый сервер проверяет DKIM запись. Заголовки и письмо не менялись. Потому что публичный ключ домена fake-bank.org подтверждает это.
  8. Почтовый сервер пропускает письмо как валидное.
  9. Клиент открывает письмо и видит, что оно отправлено от менеджера его банка.
  10. Происходит подлог. И это проблема безопасности.

Вывод.

  • Без DMARC записи SPF и DKIM не работают. Нужно использовать DMARC совместно с SPF и DKIM. Именно DMARC задает действие при котором SPF или DKIM не проходят проверку.
    DMARC позволяет использовать соответствие (alignment) поля FROM: полю MAIL FROM:.
  • DMARC указывает действие (p=), которое должен совершить получатель письма, если DKIM и SPF не проходят проверку. Если один из них проходит, то письмо валидное.
  • Чтобы прошла DKIM проверка. Домен в DKIM заголовке письма (DomainKey-Signature: a=rsa-sha1;s=selector;d=fake-bank.org) должен соответствовать домену в поле FROM (bank.org).
  • Чтобы прошла SPF проверка. Домен в RFC5321.MailFrom (MAIL FROM) или RFC5321.EHLO/HELO поле SMTP должен соответствовать домену в поле FROM (bank.org).
  • Если ни одна из проверок не проходит, то письмо невалидное. Клиент применяет политику, указанную в записи DMARC.
  • В рассматриваемом примере проверка DKIM не пройдет.

DMARCv=dmarc1;p=none. Публикуется в поддомене _dmarc.bank.org. Защищает получаетеля сфабрикованного письма от домена bank.org от злоумышленника.

Проверка записи DMARC

nslookup -type=TXT _dmarc.bank.org

Проверка записи SPF

nslookup -type=TXT bank.org

Проверка записи DKIM

nslookup -type=TXT selector._domainkey.bank.org

Источник 1
Источник 2
Источник 3
Источник 4
Источник 5
Источник 6
Источник 7
Источник 8
Источник 9
Источник 10
Источник 11

2. HTTP2 connection reuse и reverse proxy

HTTP2 использует TLS1.2 и выше для шифрования и аутентификации. Клиент по TLS указывает в поле SNI к какому серверу идет подключение. Таким образом адрес сайта передается два раза: в TLS Client Hello поле SNI и в HTTP заголовоке Host.

Небольшое отклонение: в новом HTTP они перевели HTTP/1.1 Host заголовок в HTTP/2 :authority заголовок. И с их использованием возникают проблемы. 😐
Использование заголовка :authority в HTTP2 для той роли, что играл заголовок Host в HTTP1.1 имеет объяснение. Название идет из RFC 3986, в котором authority имеет следующий вид
authority = [ userinfo "@" ] host [ ":" port ]
Однако часть userinfo обозначается устаревшей и запрещается к использованию в HTTP2. Т.е. в authority будет включен имя хоста и порт опционально.

А еще в HTTP3 версии (т.е. в следующей после HTTP2) они убрали поддержку передачи открытым тексктом (в HTTP2 была такая возможность) и перевели на транспортный протокол UDP.

HTTP2 использует постоянное подключение. При подключении к одному северу на один порт клиент предпочтительно будет использовать установленное подключение.
Из-за этого может произойти объединение (HTTP2 coalescing). Два сервера за обратным прокси начинают выглядеть для клиента как один. Т.е. в HTTP2 когда адрес резолвится в IP адрес и совпадает с предыдущим IP и сертификат совпадает с предыдущим сертификатом, то используется текущее соединение. В HTTP1.1 каждый запрос создавал новое подключение. И это проблема безопасности.

Пример

  • Обратный прокси (HAProxy)
  • Два HTTPS веб сайта опубликованы на нем: site1.example.org и site2.example.org
  • Прокси использует использует SNI из запроса для направления на веб сервер (SNI proxy)
    • site1 располагается на веб сервере .1
    • site2 располагается на веб сервере .2
  • Оба веб сайта используют один wildcard *.example.org сертификат
  1. Клиент веб браузер подключается к первому сайту site1.example.org
  2. Клиент получает адрес обратного прокси
  3. Клиент запускает этап согласования TLS
  4. Прокси получает TLS Client Hello
  5. В SNI запроса указан сайт подключения — site1.example.org
  6. Прокси пропускает запрос на веб сервер .1
  7. Клиент получает сертификат сайта *.example.org
  8. Клиент успешно подключается
  9. Клиент запрашивает подключение ко второму сайту site2.example.org
  10. Веб браузер видит, что IP адрес и сертификат те же самые
  11. Клиент использует HTTP2 установленное соединение
  12. Клиент пропускает этап согласования TLS
  13. Прокси не получает TLS Client Hello
  14. Прокси использует существующее подключение
  15. Прокси пропускает запрос на веб сервер .1 вместо .2
  16. Веб сервер .1 получает данные, предназначенные для веб сервера .2. И это проблема.
  17. Клиент получает ошибку 404

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

Misdirected Request
The client needs a new connection for this request
as the requested host name does not match the Server Name Indication (SNI)
in use for this connection.

Вывод.

Отключить HTTP2 на стороне сервера. Если это возможно. Например HTTP2 также не поддерживает аутентификацию Windows authentication (NTLM/Kerberos/Negotiate) там сломаны картинки

Чтобы в IIS отключить HTTP2:

  1. Пуск → regedit
  2. Открыть путь: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters
  3. В папке Parameters, правой кнопкой мыши создать 2 новых DWORD (32-bit) значения:
  4. EnableHttp2Tls
    EnableHttp2Cleartext

  5. Проверить что оба зачения установлены в 0(отключено) изменив нажав правую кномку мыши и выбрав «Изменить…»
  6. Перезагрузить систему

Другой вариант. Использовать разные сертификаты. Или использовать разные IP адреса.

Начиная с 1 сентярбя 2020 браузеры перестанут принимать сертификаты дольше чем на 398 дней.

Источник 1
Источник 2
Источник 3
Источник 4
Источник 5
Источник 6
Источник 7
Источник 8
Источник 9
Источник 10
Источник 11
Источник 12
Источник 13
Источник 14
Источник 15
Источник 16
Источник 17
Источник 18
Источник 19
Источник 20
Источник 21

Вторая часть.

HTTP Boot замена PXE

Ранее в блоге был пост про PXE загрузку. Установка Windows по сети. За подробностями можно перейти почитать. Если вкратце. Настроив DHCP сервер можно указать клиенту сетевое расположение установочного образа системы (NBP).

Прогресс не стоит на месте и на место PXE приходит HTTP Boot. Про сравнение двух подходов и пойдет речь.

Первое, что нужно знать про HTTP Boot — он работает только на системах UEFI версии 2.5 и выше. Поэтому если у вас по-прежнему используется BIOS возможно следует обновиться. Тем более что крупнейший производитель чипов Intel собирается прекратить поддержку BIOS после 2020. Напоминание, что переключение с BIOS на UEFI загрузку требует изменения в установленной ОС.

Дальше вспомним про работу PXE.

Загрузка в PXE

Процесс загрузки PXE использует несколько протоколов.

  1. DHCP
    1. Клиент передает опцию PXEClient
    2. Сервер передает опцию сервера загрузки и опцию имени файла загрузки
  2. TFTP
    Клиент скачивает образ Network Bootstrap Program (NBP)
  3. Запуск исполняемого образа
    Передача управления ему. Дальнейшая загрузка использует протоколы, реализованные в самом образе. Так для Windows это SMB протокол.

Читать далее

Wireshark дешифрока HTTPS

Все больше в современных сетях используется шифрование с помощью TLS. Благодаря чему в ПО захвата пакетов, таком как Wireshark, невозможно увидеть внутренности пакета. В этом посте рассказывается про асимметричное шифрование, TLS в версии 1.3 и как можно расшифровать его пакеты в Wireshark.

Содержание:

  • Введение в шифрование с открытым ключом
  • Реализация шифрования в TLS
  • Отличие TLS версии 1.3
  • Дешифровка TLS с помощью Wireshark

Введение.

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

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

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


Читать далее

Skype for Business и Juniper SRX внешний доступ

Небольшой пост по конкретной проблеме в взаимодействии Skype for Business и Juniper SRX.

Проблема: Показ экрана работает внутри сети. Показ экрана не работает при подключении снаружи.

Проблема оказалась в следующем:

Что происходит по шагам:

  1. SfB клиент инициирует TCP подключение отправив SYN сегмент
  2. SfB сервер сбрасывает это TCP подключения отправив RST сегмент
  3. Juniper записывает эту TCP сессию на удаление через 2 секунды
  4. Клиент снова инициирует TCP подключение с теми же самими параметрами (IP адрес источника, IP адрес получателя, порт и протокол)
  5. Сервер принимает TCP подключение
  6. Но для Juniper эта та же самая сессия, помеченная для удаления
  7. Спустя приблизительно 1,5 секунды с момента установления TCP сессии Juniper разрывает сессию
  8. Все следующие пакеты от клиента будут отбрасываться Juniper потому что они не подпадают ни под одну отслеживаемую сессию. И они не смогу создать новую сессию потому что не содержат SYN флага.

Проблемы могло бы не быть, если выполнялось одно из условий:

  • Клиент Skype for Business инициировал каждое новое соединение TCP с новым портом
  • SRX закрывал TCP сессию сразу при получении RST сегмента

К счастью, в SRX существует возможность отключить 2 секундное ожидание перед разрывом TCP сессии. Существует даже отдельная KB на сайте Juniper посвященная этой проблеме [2].

В разделе конфигурации security flow tcp-session есть параметры изменяющие работу с TCP сессиями. Нас интересует настройка rst-invalidate-session. Если ее включить, то соединение будет разрываться сразу при получении RST сегмента.

Решение кратко:
В режиме конфигурации SRX ввести

set security flow tcp-session rst-invalidate-session
commit
exit

Источник 1

Источник 2

Исследуем аутентификацию в IIS

Протокол аутентификации Kerberos уже затрагивался в этом блоге ранее. В этом посте пойдет речь про аутентификацию Kerberos, NTLM и Negotiate в веб-сервере IIS. Будет проверено на практике какой протокол аутентификации используется в том или ином случае. Для этого будет проведен несколько тестов в каждом из которых будет сделан вывод. Все выводы можно прочитать в конце поста.

Kerberos

Начнем с общего описания аутентификации Kerberos. Пользователь заходит на рабочую станцию (клиент) в домене. Для аутентификации клиент связывается с центром выдачи ключей (key distribution center, KDC), для Windows это контроллер домена. Контроллер домена проверяет, что логин и хеш пароля, введенные пользователем, совпадают с хранящимися в базе KDC. Если учетные данные корректны, центр выдает удостоверение (ticket-granting ticket, TGT), подписанное особенным доменным пользователем krbtgt. TGT используется для подтверждения, что пользователь прошел аутентификацию. После этого пользователь подключается к какому-либо ресурсу в домене, например, общей папке на файловом сервере. Клиент обращается к KDC, прилагая TGT, за выдачей удостоверения запрашиваемого сервиса (service ticket, TGS). Контроллер домена проверяет, что такой сервис совпадает с хранящимся в базе KDC и выдает клиенту TGS. После этого клиент обращается к файловому серверу, прилагая TGS. Файловый сервер видит, что TGS выдан контроллером домена и принимает подключение пользователя.

Процесс показан на рисунке

Подключившись доменным пользователем можно вывести как TGT:

klist tgt

Так и TGS:

klist

Читать далее

Два изменения в безопасности Windows

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

Групповая политика (GPO) после MS16-072/KB3163622

В июне 2016 года Microsoft выпустила бюллетень безопасности MS16-072, который включал в себя обновления для Windows 10 и Windows Server 2016 (а также более старых версий). Обновление изменило процесс применения групповой политики.

Групповая политика состоит из двух разделов: компьютера и пользователя. Если раньше раздел пользователя применялся под учетной записью пользователя, унаследовавшего политику, то после обновления user group policy применяется под учетной записью компьютера, на который зашел пользователь.

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

В настройках по умолчанию фильтр включает группу Authenticated Users, которая включает учетные записи пользователей и компьютеров в домене. Если настройка фильтра по умолчанию вам не подходит, то можно создать доменную группу в которую включить нужные компьютеры (или использовать группу Domain Computers) и выдать ей права на чтение в фильтре.

Пример фильтра групповой политики.

Настройка доступа групповой политики Test GPO, чтобы она распространялась на пользователя test.user на какой бы доменный компьютер он не зашел:


Читать далее

Filezilla ENETUNREACH или как антивирусы сканируют трафик

По запросу «Filezilla ошибка ENETUNREACH» поисковая система выдает, что проблема в антивирусе (Касперский) и для ее решения необходимо добавить filezilla.exe в исключения (доверенные приложения). На форуме этого FTP клиента описывается механизм как антивирус анализурует трафик приложения. Дальше будет приведен перевод:

 Касперский перенаправляет весь сетевой трафик через свой процесс avp.exe по адресу 127.0.0.1 порт 1110.

Как просходит нормальное FTP подключение без сетевого сканирования:

  1. Filezilla создает управляющее TCP-соединение до адреса 93.184.216.23
  2. Операционная система назначает адрес источника IP пакета как адрес исходящего интерфейса допустим 10.0.0.123
  3. После установления соединения для передачи команд Filezilla создает соединение для передачи данных
  4. Адреса источника и получателя IP пакета используются те же, что и в управляющем соединении Т.е. у соеденения для передачи данных адрес источника будет 10.0.0.123, а получателя — 93.184.216.23.

Читать далее

Удаление нерабочего контроллера домена

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

Первым делом стоит подтвердить, что все FSMO роли принадлежат рабочему контроллеру домена. Для этого понадобится членство в группах: Domain Admins, Enterprise Admins, Schema Admins.

FSMO роли являются критическими функциями без которых работа домена будет испытывать трудности. Они разделяются на два уровня:

  1. Уровень леса (forest level):
    • Schema master
    • Domain naming master
  2. Уровень домена (domain level):
    • RID master
    • PDC
    • Infrastructure master

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

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

Читать далее

Удаленный доступ по WMI и PowerShell для неадминистраторв

Это перевод статьи Ondrej Sevecek о настройке удаленного доступа WMI и PowerShell по протоколу WinRM для пользователей без прав администратора.

WinRM, также называемый WSMan, это технология удаленного управления, которая предоставляет для таких средств как WMI, PowerShell, Перенаправление событий (Event Forwarding) и даже Диспетчер сервера (Server Manager) транспорт по протоколу HTTP. WinRM принимает запросы по HTTP или HTTPS протоколу, которые затем передает зарегистрированным в нем провайдерам (плагинам). PowerShell, WMI и Перенаправление событий зарегистрированы в WinRM как соответствующие провайдеры.

Если бы вы были разработчиком клиент-серверного приложения, то вы могли бы создать свой провайдер (плагин) для WinRM, который можно было бы использовать для удаленного управления вашим приложением. Конечно можно и самому написать DCOM или HTTP веб-интерфейс, но WinRM предоставляет стандартный каркас приложения (фреймворк), что облегчает его администрирование.

WinRM поддерживает методы встроенной аутентификации Windows, такие как Kerberos, Negotiate (включая NTLM) и Schannel (сертификаты). Поскольку он использует обычный HTTP, то поддерживаются также методы аутентификации Basic и Digest.

Для удаленного доступа к инструментарию управления Windows (WMI, winmgmt) можно настроить специальный DCOM интерфейс на прием удаленных команд и запросов (WQL), или же использовать WinRM для этого. PowerShell, с другой стороны, не имеет своего собственного сервера, поэтому для приема удаленных команд используются специальные командлеты Enter-PSSession и Invoke-Command, которые передают запросы по WinRM протоколу. PowerShell принимает эти команды, обрабатывает их локально и возвращает ответ по протоколу WinRM.

Таким же образом работает Диспетчер сервера (Server Manager) и Перенаправление событий (Event Forwarding). Хотя у перенаправления событий, есть свой сервис Windows Event Collector (wecsvc), но Microsoft решила использовать WinRM для пересылки сообщений.

Читать далее