Port domyślny 1433

Port 1433 to domyślny port instancji SQL Server — jego zmiana bywa stosowana jako dodatkowe utrudnienie dla skanowania.

Rola portu 1433 w SQL Server

Port 1433 jest domyślnym portem TCP używanym przez domyślną instancję silnika Microsoft SQL Server. TCP zapewnia zestawienie połączenia między klientem a usługą serwera oraz dostarczanie danych w prawidłowej kolejności. Jeżeli usługa SQL Server działa na standardowej konfiguracji i korzysta z domyślnej instancji, aplikacja kliencka może próbować połączyć się z adresem serwera przy użyciu numeru portu 1433. Numer portu nie identyfikuje samodzielnie konkretnej bazy danych. Wskazuje punkt komunikacyjny usługi, która następnie obsługuje uwierzytelnianie, wybór bazy i wykonywanie zapytań.

Warto rozróżnić nazwę instancji od numeru portu. Domyślna instancja SQL Server jest zwykle identyfikowana nazwą komputera lub adresem IP bez dopisywania nazwy instancji. Instancja nazwana może natomiast korzystać z innego portu, często przydzielanego dynamicznie. W takim przypadku klient może korzystać z usługi SQL Server Browser, która używa portu UDP 1434 do przekazywania informacji o portach instancji nazwanych. Nie oznacza to, że port UDP 1434 zastępuje port TCP używany przez sam silnik bazy danych.

Połączenie klienta z usługą na porcie TCP

Podczas nawiązywania połączenia klient SQL Server, sterownik aplikacji albo narzędzie administracyjne musi znać adres hosta oraz port, na którym nasłuchuje właściwa usługa. Przykładowo adres zapisany jako serwer,1433 oznacza próbę połączenia z hostem o nazwie serwer przez TCP na porcie 1433. W konfiguracji aplikacji spotyka się również adres IP wraz z numerem portu, na przykład 192.0.2.10,1433. Składnia zależy od używanego sterownika i biblioteki, dlatego sam zapis nie jest uniwersalną komendą dla każdej aplikacji.

Jeżeli połączenie nie działa, trzeba odróżnić kilka różnych sytuacji. Brak nasłuchu na porcie może oznaczać zatrzymaną usługę SQL Server, użycie innego portu, nieprawidłową konfigurację protokołu TCP/IP albo działanie instancji nazwanej. Z kolei komunikat o przekroczeniu czasu oczekiwania często wskazuje na zaporę sieciową, niedostępność hosta lub filtrowanie ruchu, ale nie rozstrzyga samodzielnie, która z tych przyczyn wystąpiła. Połączenie z otwartym portem nie gwarantuje poprawnego logowania: późniejszy etap może zakończyć się błędem uwierzytelniania, brakiem uprawnień albo próbą wybrania nieistniejącej bazy.

Zmiana numeru portu a bezpieczeństwo SQL Server

Administrator może skonfigurować SQL Server tak, aby nasłuchiwał na innym stałym porcie TCP zamiast na 1433. Zmiana numeru może ograniczyć część automatycznych skanów kierowanych wyłącznie na typowy port, ale jest to utrudnienie organizacyjne, a nie samodzielny mechanizm ochrony. Skaner, który bada wiele portów albo korzysta z informacji o konfiguracji, może znaleźć usługę również po zmianie numeru. Nie należy więc traktować niestandardowego portu jako zamiennika zapory, kontroli dostępu, aktualizacji i prawidłowego uwierzytelniania.

Przy zmianie portu trzeba zaktualizować wszystkie elementy, które nawiązują połączenie z instancją: ciągi połączeń, konfigurację sterowników, reguły zapory na serwerze oraz ewentualne reguły filtrujące ruch między sieciami. Jeżeli instancja korzysta z portu dynamicznego, numer może zmienić się po ponownym uruchomieniu usługi, co powoduje niestabilność połączeń, gdy aplikacja oczekuje stałej wartości. W środowisku wymagającym przewidywalnej komunikacji stosuje się stały port i dokumentuje jego użycie. Po każdej zmianie należy sprawdzić zarówno nasłuch lokalny, jak i połączenie z hosta klienckiego.

Sprawdzanie konfiguracji i przyczyny niedostępności

Weryfikację można rozpocząć od ustalenia, czy uruchomiona instancja rzeczywiście jest domyślną instancją SQL Server oraz jaki port TCP ma skonfigurowany protokół TCP/IP. Następnie sprawdza się, czy usługa nasłuchuje na właściwym interfejsie sieciowym, a nie wyłącznie na adresie lokalnym. Sam fakt, że port 1433 jest otwarty na komputerze, nie dowodzi jeszcze, że zdalny klient może z niego skorzystać. Znaczenie mają również adres docelowy, trasa sieciowa i reguły zapory.

W przypadku instancji nazwanej należy ustalić jej rzeczywisty port zamiast zakładać użycie 1433. Gdy wykorzystywany jest SQL Server Browser, trzeba osobno rozważyć dostępność UDP 1434, ponieważ służy on do odnajdywania informacji o instancjach, a nie do przesyłania właściwej sesji SQL. Jeżeli port jest dostępny, lecz klient nadal odrzuca połączenie, dalsza diagnostyka powinna obejmować wersję i konfigurację sterownika, metodę uwierzytelniania, nazwę instancji oraz logi SQL Server. W razie potrzeby analizuje się także negocjowanie szyfrowania połączenia i zgodność ustawień certyfikatu, ponieważ poprawna komunikacja sieciowa nie eliminuje problemów występujących podczas ustanawiania bezpiecznej sesji.