Tag Archives: Windows

HTTP Boot замена PXE

Posted on 30.12.2019 | Оставьте комментарий

Ранее в блоге был пост про 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 протокол.

Читать далее →

Оставьте комментарий

Рубрика: Cтатьи

Отмечено ,

Wireshark дешифрока HTTPS

Posted on 22.04.2018 | Оставьте комментарий

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

Содержание:

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

Введение.

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

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

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


Читать далее →

Оставьте комментарий

Рубрика: Cтатьи

Отмечено ,

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

Posted on 24.12.2017 | Оставьте комментарий

Небольшой пост по конкретной проблеме в взаимодействии 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

Оставьте комментарий

Рубрика: Cтатьи

Отмечено , ,

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

Posted on 03.09.2017 | Оставьте комментарий

Протокол аутентификации 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

Читать далее →

Оставьте комментарий

Рубрика: Cтатьи

Отмечено ,

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

Posted on 20.08.2017 | Оставьте комментарий

Если программа находится в процессе разработки, то помимо нового функционала в ней может меняться и самые базовые вещи. Операционные системы не исключение. В данном посте будет рассказано про два изменения в 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 на какой бы доменный компьютер он не зашел:


Читать далее →

Оставьте комментарий

Рубрика: Cтатьи

Отмечено

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

Posted on 26.06.2017 | Оставьте комментарий

По запросу «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.

Читать далее →

Оставьте комментарий

Рубрика: Cтатьи

Отмечено ,

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

Posted on 18.02.2016 | Оставьте комментарий

Ниже будет приведена краткая инструкция о том, как, используя утилиту 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, вам может понадобиться переместить лишь три роли уровня домена (если нерабочий контроллер не является коренным в лесу) или же все пять.

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

Читать далее →

Оставьте комментарий

Рубрика: Cтатьи

Отмечено ,