Поделиться через

Трассировка процесса проверки сетевой подлинности до ядра СУБД

  • Статья

В этой статье представлено несколько примеров сетевой трассировки, которая фиксирует различные рукопожатия и последовательности проверки подлинности во время установки TCP-соединения между клиентским приложением и СУБД SQL Server (сервером).

Сведения о закрытии подключений см. в разделе Трассировка последовательности закрытия сетевого подключения в ядро СУБД.

Типы аутентификации

Вы можете подключиться к ядру СУБД с аутентификацией Windows (с помощью аутентификации Kerberos или аутентификации NTLM) или аутентификации SQL.

В этой статье также описываются подключения с несколькими активными результирующими наборами (MARS). MARS — это функция SQL Server, представленная в SQL Server 2005 (9.x), которая позволяет выполнять несколько команд в соединении без необходимости очистки результатов из первой команды перед выполнением второй команды. MARS реализуется с помощью мультиплексирования сеансов (SMUX).

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

  1. Трехстороннее рукопожатие TCP
  2. Подтверждение водителя
  3. Установка соединения SSL/TLS
  4. Обмен пакетами входа
  5. Подтверждение входа
  6. Выполнение команды и чтение ответа
  7. Четырехфазное завершение соединения TCP

Пример трассировки сети

Этот обмен выделяется 1 секунду независимо от Login Timeout установки в строке подключения.

  • IP-адрес клиента 10.10.10.10
  • IP-адрес сервера 10.10.10.120

Шаг 1. Трехстороннее рукопожатие TCP

Все TCP-беседы начинаются с пакета SYN (установлен флаг S), отправленного от клиента к серверу. В Frame 6127клиент использует временный порт (динамически назначенный операционной системой) и подключается к порту сервера в данном случае 1433. Сервер отвечает пакетом SYN, в котором также установлен флаг ACK. Наконец, клиент отвечает пакетом ACK , чтобы сообщить серверу, что он получил свой SYN пакет.

На этом шаге устанавливается базовое TCP-подключение, так же как это сделала бы команда telnet. Операционная система медиатирует эту часть беседы. На этом этапе клиент и сервер ничего не знают друг о другом.

Схема трехэтапного установления соединения. 

Frame Time Offset Source IP    Dest IP      Description
----- ----------- ------------ ------------ ---------------------------------------------------------------------------------------------------
6127  116.5776698 10.10.10.10  10.10.10.120 TCP:Flags=......S., SrcPort=60123, DstPort=1433, PayloadLen=0, Seq=4050702293, Ack=0, Win=8192 ( Ne
6128  116.5776698 10.10.10.120 10.10.10.10  TCP:Flags=...A..S., SrcPort=1433, DstPort=60123, PayloadLen=0, Seq=4095166896, Ack=4050702294, Win=
6129  116.5786458 10.10.10.10  10.10.10.120 TCP:Flags=...A...., SrcPort=60123, DstPort=1433, PayloadLen=0, Seq=4050702294, Ack=4095166897, Win=

На этом этапе [Bad CheckSum] предупреждения безвредны и указывают на то, что включена разгрузка контрольной суммы. То есть они добавляются на более низком уровне в сетевом стеке, чем уровень, на котором берётся трассировка. В отсутствие других сведений это предупреждение указывает, была ли трассировка сети выполнена на клиенте или сервере. В этом случае он отображается в исходном SYN пакете, поэтому трассировка была сделана на клиенте.

Шаг 2. Рукопожатие драйвера

Как драйвер клиента, так и SQL Server должны знать немного о друге. В этом рукопожатии драйвер отправляет на сервер некоторые сведения и требования. Эти сведения содержат сведения о том, следует ли шифровать пакеты данных, использовать ли несколько активных результирующих наборов (MARS), его номер версии, использовать федеративную проверку подлинности, GUID подключения и т. д.

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

Схема рукопожатия драйвера. 

Frame Time Offset Source IP    Dest IP      Description
----- ----------- ------------ ------------ ---------------------------------------------------------------------------------------------------
6130  116.5786458 10.10.10.10  10.10.10.120 TDS:Prelogin, Version = 7.1 (0x71000001), SPID = 0, PacketID = 0, Flags=...AP..., SrcPort=60123, Ds
6131  116.5805998 10.10.10.120 10.10.10.10  TDS:Response, Version = 7.1 (0x71000001), SPID = 0, PacketID = 1, Flags=...AP..., SrcPort=1433, Dst

Шаг 3. Процесс рукопожатия SSL/TLS

Рукопожатие SSL/TLS начинается с пакета Client Hello, за которым следует пакет Server Hello, а также некоторые дополнительные пакеты, связанные с безопасным каналом. Этот шаг заключается в том, что ключ безопасности согласовывается для шифрования пакетов. Как правило, только пакет входа шифруется, но клиент или сервер могут требовать шифрования пакетов данных. Выбор версии TLS происходит на этом этапе входа. Клиент или сервер могут закрыть подключение на этом этапе, если версии TLS не совпадают или у них нет совместимых наборов шифров.

Схема рукопожатия SSL/TLS. 

Frame Time Offset Source IP    Dest IP      Description
----- ----------- ------------ ------------ ---------------------------------------------------------------------------------------------------
6132  116.5835288 10.10.10.10  10.10.10.120 TLS:TLS Rec Layer-1 HandShake: Client Hello. {TLS:328, SSLVersionSelector:327, TDS:326, TCP:325, IP
6133  116.5845058 10.10.10.120 10.10.10.10  TLS:TLS Rec Layer-1 HandShake: Server Hello. Certificate. Server Hello Done. {TLS:328, SSLVersionSe
6134  116.5864588 10.10.10.10  10.10.10.120 TLS:TLS Rec Layer-1 HandShake: Client Key Exchange.; TLS Rec Layer-2 Cipher Change Spec; TLS Rec La
6135  116.5923178 10.10.10.120 10.10.10.10  TLS:TLS Rec Layer-1 Cipher Change Spec; TLS Rec Layer-2 HandShake: Encrypted Handshake Message. {TL

Шаг 4. Пакет входа

Этот пакет зашифрован и может отображаться как SSL Application Data или TDS:Dataв зависимости от сетевого синтаксического анализа. Если все пакеты после этого шага также отображаются как SSL Application Data, подключение шифруется.

Схема входа SQL. 

Frame Time Offset Source IP    Dest IP      Description
----- ----------- ------------ ------------ ---------------------------------------------------------------------------------------------------
6136  116.5932948 10.10.10.10  10.10.10.120 TLS:TLS Rec Layer-1 SSL Application Data {TLS:328, SSLVersionSelector:327, TDS:326, TCP:325, IPv4:3

Шаг 5. Подтверждение входа

В противном случае отображается пакет ответа, который подтверждает имя входа (имеет маркер входа ACK ) или возвращает Login Failed сообщение об ошибке клиенту.

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

.C.h.a.n.g.e.d. .d.a.t.a.b.a.s.e. .c.o.n.t.e.x.t. .t.o. .'.A.d.v.e.n.t.u.r.e.W.o.r.ks'

Схема подтверждения входа SQL. 

Frame Time Offset Source IP    Dest IP      Description
----- ----------- ------------ ------------ ---------------------------------------------------------------------------------------------------
6137  116.5962248 10.10.10.120 10.10.10.10  TDS:Response, Version = 7.1 (0x71000001), SPID = 96, PacketID = 1, Flags=...AP..., SrcPort=1433, Ds

Шаг 6. Выполнение команды и чтение ответа

Команды отправляются либо как пакет TDS:SQLBatch, либо как пакет TDS:RPCRequest. Первый выполняет обычные инструкции Transact-SQL, а последний выполняет хранимые процедуры. Вы можете увидеть пакеты продолжения TCP, если команда длинная, или в ответном пакете, если возвращается больше чем несколько строк.

Frame Time Offset Source IP    Dest IP      Description
----- ----------- ------------ ------------ ---------------------------------------------------------------------------------------------------
6138  116.5991538 10.10.10.10  10.10.10.120 TDS:SQLBatch, Version = 7.1 (0x71000001), SPID = 0, PacketID = 1, Flags=...AP..., SrcPort=60123, Ds
6139  116.5991538 10.10.10.120 10.10.10.10  TDS:Response, Version = 7.1 (0x71000001), SPID = 96, PacketID = 1, Flags=...AP..., SrcPort=1433, Ds
6266  116.8032558 10.10.10.10  10.10.10.120 TCP:Flags=...A...., SrcPort=60123, DstPort=1433, PayloadLen=0, Seq=4050702956, Ack=4095168204, Win=

Шаг 7. Четырехстороннее закрытие соединения TCP

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

Четырехстороннее подтверждение состоит в том, что клиент отправляет пакет FIN на сервер, на который сервер отвечает сообщением ACK. Затем сервер отправляет свой собственный FIN пакет, который клиент признает (ACK).

Если сервер сначала отправляет пакет FIN, это ненормальное закрытие; чаще всего это происходит при рукопожатии SSL/TLS, если клиент и сервер не могут согласовать безопасный канал.

Схема четырехфазного закрытия обмена. 

Frame Time Offset Source IP    Dest IP      Description
----- ----------- ------------ ------------ ---------------------------------------------------------------------------------------------------
6362  116.9097008 10.10.10.10  10.10.10.120 TCP:Flags=...A...F, SrcPort=60123, DstPort=1433, PayloadLen=0, Seq=4050702956, Ack=4095168204, Win=
6363  116.9097008 10.10.10.120 10.10.10.10  TCP:Flags=...A...., SrcPort=1433, DstPort=60123, PayloadLen=0, Seq=4095168204, Ack=4050702957, Win=
6364  116.9097008 10.10.10.120 10.10.10.10  TCP:Flags=...A...F, SrcPort=1433, DstPort=60123, PayloadLen=0, Seq=4095168204, Ack=4050702957, Win=
6366  116.9106778 10.10.10.10  10.10.10.120 TCP:Flags=...A...., SrcPort=60123, DstPort=1433, PayloadLen=0, Seq=4050702957, Ack=4095168205, Win=

Связанный контент