Czy nadal najlepszą praktyką jest unikanie używania domyślnych portów dla SQL Server?

Historycznie zaleca się, aby nie używać domyślnych portów do połączeń z SQL Server, jako część najlepszej praktyki bezpieczeństwa. Na serwerze z pojedynczą, domyślną instancją domyślnie używane będą następujące porty:

• Usługa SQL Server - Port 1433 (TCP)
• Usługa przeglądarki SQL Server - Port 1434 (UDP)
• Dedykowane połączenie administracyjne - port 1434 (TCP)

PYTANIA:

• Czy ta rada jest nadal aktualna?
• Czy WSZYSTKIE powyższe porty należy zmienić?

Historycznie zaleca się, aby nie używać domyślnych portów do połączeń z SQL Server, jako część najlepszej praktyki bezpieczeństwa.

Co było niegdyś asyninowe, a teraz jeszcze asininowe. Bezpieczeństwo poprzez zapewne niejasność wcale nie jest bezpieczeństwem.

Czy ta rada jest nadal aktualna?

IMHO to nigdy nie miało znaczenia. Było to wymagane dla niektórych celów zgodności, ponieważ ludzie opracowujący te zgodność nie rozumieli, co robią, ponownie, IMHO.

Czy WSZYSTKIE powyższe porty należy zmienić?

Nie zmieniłbym żadnej.

Chociaż bezpieczeństwo poprzez zaciemnienie nie jest faktycznym zabezpieczeniem, nie powiem, że nie ma żadnych przypadków, w których to pomaga.

Jeśli atakujący chce wiedzieć, gdzie nasłuchuje Twoja usługa, może łatwo się dowiedzieć, ale w przypadku głupiego zautomatyzowanego ataku możesz mieć szczęście, jeśli zmienisz port.

Jedyny raz, kiedy pamiętam, w czym faktycznie pomógł, to w czasach SQL Slammera, gdzie SQL Server 2000 był podatny na ataki, a robak rozprzestrzeniał się, generując losowe adresy IP i łącząc się z domyślnym portem przeglądarki SQL Server.

Jeśli dobrze pamiętam, w tamtych czasach oficjalną radą była zmiana portów, dopóki nie będzie można załatać serwera (albo dlatego, że łatka nie była dostępna natychmiast, albo dlatego, że nie masz okna)

Aby ten robak wszedł do sieci w momencie, gdy trzeba było mieć SQL Server podłączony do Internetu zamiast za zaporą ogniową, czego nie powinieneś, ale w każdym razie inny niż domyślny numer portu mógł pomóc w tym konkretnym przypadku.

Zgadzam się jednak, że jeśli masz odpowiednie zabezpieczenia, złożoność, którą dodasz, prawdopodobnie nie przeważa nad szansami zapobiegania incydentowi.

Historycznie zaleca się, aby nie używać domyślnych portów do połączeń z SQL Server, jako część najlepszej praktyki bezpieczeństwa

Nie, nie było. Być może niektórzy wprowadzeni w błąd ludzie przedstawili to jako takie, ale robię zabezpieczenia od ponad 20 lat, a zmiana domyślnych portów zawsze była swego rodzaju „tutaj jest coś, co możesz zrobić, jeśli chcesz, co może czasami w bardzo szczególnych okolicznościach zapewnia trochę dodatkowej ochrony przed niektórymi bardzo specyficznymi zagrożeniami.

Czy ta rada jest nadal aktualna?

W bardzo szczególnych okolicznościach, w zależności od modelu zagrożenia i analizy ryzyka, mogą wystąpić sytuacje, w których jest to dobra rada. W zdecydowanej większości przypadków nie, nie ma to znaczenia ani nigdy nie było.

TAK , nadal jest przydatny.

Zmiana domyślnych portów ma tylko jeden rzeczywisty cel: bronić się przed automatycznymi skanowaniami / atakami, jeśli serwer bazy danych jest otwarty na hosty, które mogą zostać naruszone.

Chociaż może to nie brzmieć jak wielka sprawa, pamiętaj, że:

• dowolny host może zostać przejęty (lub serwer baz danych może zostać narażony na działanie Internetu z powodu błędu)
• większość tych ataków to zautomatyzowane ataki , a wiele z nich spróbuje użyć tylko domyślnych portów (ponieważ celowanie w nisko wiszące owoce jest najbardziej wydajne).

Tak, choć samo w sobie nie pomoże ci dużo, jeśli jesteś atakowany celowo , użycie losowych portów (i / lub zmuszenie do nasłuchiwania tylko na losowym adresie IPv6) sprawi, że będzie on znacznie mniej widoczny, a tym samym da ci przynajmniej więcej czasu na uaktualnij, zanim zaatakuje Cię automatyczne skanowanie exploitów 0day (a może nawet całkowicie samo zabezpieczy przed takim automatycznym skanowaniem!)

Ponadto (pomoże to nie tylko przeciwko wszystkim automatycznym atakom, ale także przeciwko niektórym atakom ukierunkowanym), gdy osoby atakujące próbują znaleźć port bazy danych w celu wykorzystania go przy użyciu skanowań portów bruteforce, można go wykryć i obronić (poprzez umieszczenie na czarnej liście zakresów adresów IP atakujących i ostrzeganie administratorów, jeśli jakiś wewnętrzny host został wykryty jako źródło ataku)

Należy również pamiętać, że zmiana domyślnego portu dla serwera i klientów (szczególnie jeśli są one wdrażane automatycznie) to banalna ilość pracy, a wykrywanie skanów bruteforce jest również łatwe; więc naprawdę powinieneś to robić (nie tylko dla serwerów baz danych; ale dla wszystkich usług, w których narzut związany z konfiguracją nie jest zbyt wysoki ze względu na problemy z użytecznością: taka zmiana domyślnego portu dla sieci 80nie jest zalecana, ponieważ niektóre osoby (i boty) zepsuje to, a losowe zapory ogniowe na całym świecie mogą nie zezwalać na nawiązanie połączenia. Ale protokół RDP jest doskonałym celem na przykład dla portu innego niż domyślny)

Nie zmieniłbym portu, ale nigdy nie ujawniłem usługi bazy danych bezpośrednio przez Internet. Tylko przez bezpieczny tunel, taki jak SSH. Zmiana portu SSH może być dobrym pomysłem, aby zminimalizować ruch skanerów.