Udostępnij za pośrednictwem

Prześledzenie procesu uwierzytelniania sieciowego do silnika bazy danych

  • Artykuł

W tym artykule przedstawiono kilka przykładów śledzenia sieci, który przechwytuje różne uściski dłoni i sekwencje uwierzytelniania podczas procesu ustanawiania połączenia protokołu Transmission Control Protocol (TCP) między aplikacją kliencką a aparatem bazy danych programu SQL Server (serwerem).

Aby uzyskać informacje na temat zamykania połączeń, zobacz Śledzenie sekwencji zamknięcia połączenia sieciowego w aparacie bazy danych.

Typy uwierzytelniania

Możesz nawiązać połączenie z aparatem bazy danych przy użyciu uwierzytelniania windows (przy użyciu Kerberos lub uwierzytelniania NTLM) lub uwierzytelniania SQL.

W tym artykule opisano również wiele aktywnych połączeń zestawów wyników (MARS). MARS to funkcja programu SQL Server, wprowadzona z programem SQL Server 2005 (9.x), która umożliwia wykonywanie wielu poleceń w połączeniu bez konieczności czyszczenia wyników z pierwszego polecenia przed uruchomieniem drugiego polecenia. Usługa MARS jest osiągana za pośrednictwem multipleksowania sesji (SMUX).

W tym procesie opisano normalny proces logowania przy użyciu uwierzytelniania SQL, pokazujący każdy krok konwersacji między klientem a serwerem za pomocą szczegółowej analizy śledzenia sieci. Przykładowy ślad sieci delineuje następujące kroki:

  1. Trójkierunkowe uzgadnianie protokołu TCP
  2. Uścisk dłoni kierowcy
  3. Uzgadnianie protokołu SSL/TLS
  4. Wymiana pakietów logowania
  5. Potwierdzenie logowania
  6. Wykonywanie polecenia i odczytywanie odpowiedzi
  7. Czterokierunkowe zamykanie protokołu TCP

Przykładowy ślad sieci

Ta wymiana jest przydzielana 1 sekundę niezależnie od ustawienia Login Timeout w parametrach połączenia.

  • Adres IP klienta jest 10.10.10.10
  • Adres IP serwera jest 10.10.10.120

Krok 1. Trójkierunkowe uzgadnianie protokołu TCP

Wszystkie konwersacje TCP rozpoczynają się od pakietu SYN (S zestawu flag) wysyłanego z klienta do serwera. W ramce 6127klient używa portu efemerycznego (dynamicznie przypisanego przez system operacyjny) i łączy się z portem serwera, w tym przypadku port 1433. Serwer odpowiada swoim pakietem SYN, w którym również ustawiono flagę ACK. Na koniec klient odpowiada pakietem ACK, aby poinformować serwer, że otrzymał pakiet SYN.

Ten krok ustanawia podstawowe połączenie TCP, tak samo jak polecenie telnet. System operacyjny pośredniczy w tej części konwersacji. W tym momencie klient i serwer nic nie wiedzą o sobie.

Diagram trójkierunkowego uzgadniania. 

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=

W tym kroku ostrzeżenia [Bad CheckSum] są łagodne i wskazują, że funkcja odciążania sumy kontrolnej jest włączona. Oznacza to, że są one dodawane na niższym poziomie w warstwie stosu sieciowego niż jest wykonywane śledzenie. W przypadku braku innych informacji to ostrzeżenie wskazuje, czy ślad sieciowy został wykonany na kliencie lub serwerze. W tym przypadku pojawia się on w początkowym pakiecie SYN, więc ślad został wykonany na kliencie.

Krok 2. Połączenie sterownika

Zarówno sterownik klienta, jak i program SQL Server muszą wiedzieć nieco o sobie. W tym uścisku dłoni sterownik wysyła pewne informacje i wymagania do serwera. Te informacje obejmują, czy należy szyfrować pakiety danych, czy używać wielu aktywnych zestawów wyników (MARS), jego numer wersji, czy używać uwierzytelniania federacyjnego, identyfikatora GUID połączenia itd.

Serwer odpowiada swoimi informacjami, takimi jak to, czy wymaga uwierzytelniania. Ta sekwencja ma miejsce przed wykonaniem jakiegokolwiek rodzaju negocjacji zabezpieczeń.

Diagram uzgadniania kierowcy. 

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

Krok 3. Uzgadnianie protokołu SSL/TLS

Handshake SSL/TLS rozpoczyna się od pakietu Client Hello, następnie pakietu Server Hello, oraz dodatkowe pakiety związane z bezpiecznym kanałem. W tym kroku klucz zabezpieczeń jest negocjowany na potrzeby szyfrowania pakietów. Zwykle tylko pakiet logowania jest szyfrowany, ale klient lub serwer może również wymagać szyfrowania pakietów danych. Wybranie wersji protokołu TLS odbywa się na tym etapie logowania. Klient lub serwer może zamknąć połączenie na tym etapie, jeśli wersje TLS się nie zgadzają, lub nie mają żadnych wspólnych zestawów szyfrów.

diagram ustalania połączenia 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

Krok 4. Pakiet logowania

Ten pakiet jest szyfrowany i może być wyświetlany jako SSL Application Data lub TDS:Data, w zależności od analizatora sieci. Jeśli wszystkie pakiety po tym kroku również są wyświetlane jako SSL Application Data, połączenie jest szyfrowane.

Diagram logowania 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

Krok 5. Potwierdzenie logowania

W przeciwnym razie zostanie wyświetlony pakiet odpowiedzi, który potwierdza logowanie (ma token logowania ACK) lub zwraca komunikat o błędzie Login Failed do klienta.

Oto przykład tego, co można zobaczyć w danych szesnastkowych pakietu w przypadku pomyślnego zalogowania:

.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'

diagram potwierdzenia logowania 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

Krok 6. Wykonywanie polecenia i odczytywanie odpowiedzi

Polecenia są wysyłane jako TDS:SQLBatch lub pakiet TDS:RPCRequest. Pierwszy wykonuje zwykłe instrukcje Transact-SQL, a drugi wykonuje procedury składowane. Możesz zobaczyć pakiety kontynuacji TCP, jeśli polecenie jest długie lub w pakiecie odpowiedzi, jeśli zostanie zwróconych więcej niż kilka wierszy.

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=

Krok 7. Czterokierunkowe zamykanie protokołu TCP

Sterowniki firmy Microsoft używają czterostronnego uzgadniania do zamykania połączeń. Wiele sterowników innych firm po prostu resetuje połączenie, by go zamknąć, co utrudnia rozróżnienie między normalnym a nietypowym zamknięciem.

Czterokierunkowe uzgadnianie składa się z klienta wysyłającego pakiet FIN do serwera, na który serwer odpowiada pakietem ACK. Następnie serwer wysyła własny pakiet FIN, który klient potwierdza (ACK).

Jeśli serwer najpierw wysyła pakiet FIN, jest to nieprawidłowe zamknięcie, najczęściej spotykane podczas uzgadniania protokołu SSL/TLS, gdy klient i serwer nie mogą wynegocjować bezpiecznego kanału.

Diagram czterokierunkowego uścisku dłoni. 

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=

Powiązana zawartość