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

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

  • Статья

В этой статье представлено несколько примеров сетевой трассировки, которая фиксирует различные подтверждения и последовательности проверки подлинности во время процесса создания подключения протокола 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 начинаются с пакета (Sнабора флагов), отправляемых SYN от клиента на сервер. В 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, а также некоторые дополнительные пакеты, связанные с Secure Channel. Этот шаг заключается в том, что ключ безопасности согласовывается для шифрования пакетов. Как правило, только пакет входа шифруется, но клиент или сервер могут требовать шифрования пакетов данных. Выбор версии 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:RPCRequest как TDS:SQLBatch пакет. Первый выполняет обычные инструкции 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

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

Четырехсторонняя подтверждение состоит из клиента, отправляющего 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=

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