Domyślny port SQL Server to 1433. Nasz administrator powiedział mi, że port musi się zmienić „ze względów bezpieczeństwa”.
Czy tak naprawdę bezpieczniej jest zmienić port? Jeśli serwer znajduje się za zaporą ogniową i zezwala na połączenia tylko z określonego zakresu adresów IP, czy to nie wystarczy?
Odpowiedzi:
Pomaga w zwalczaniu typowych skanowań portów, które można zainicjować za pośrednictwem stron internetowych skanujących porty. Ale to nie pomoże przeciwko zaangażowanemu napastnikowi. To tylko kolejna warstwa, ale nie dodaje wiele przez zaporę, jak wspomniałeś.
Jeśli Twoje serwery SQL są bezpośrednio połączone z Internetem (co nie powinno być), może zapewnić pewną ochronę, ponieważ większość ogólnych skryptów ataków używa tylko domyślnych numerów portów.
Jeśli twoje serwery SQL nie są dostępne bezpośrednio z Internetu, jest to dość bezcelowe. Każda zapora ogniowa będzie musiała umożliwić łączność ze zdalnym portem. Jak tylko uruchomię oprogramowanie klienckie na komputerze, mogę zobaczyć, jakiego portu używa SQL Server za pomocą polecenia NET STAT. W tym momencie spowolniłeś mnie dokładnie 2-3 sekundy.
Spowoduje to uszkodzenie aplikacji oczekujących portu 1433.
Niektóre aplikacje można skonfigurować, aby sobie z tym poradzić, ale należy to wdrożyć.
Po prostu zostawiłbym to. Jeśli „włamią się” do domyślnej instancji na porcie 1433, oznacza to, że masz już śrubę.
Możesz określić port dla nazwanych instancji, ale następnie port 1434 musi zostać otwarty, aby rozpoznać instancję na porcie ...
Hakerzy często skanują adresy IP w poszukiwaniu najczęściej używanych portów, więc nierzadko używa się innego portu do „latania pod radarem”. Ma to na celu uniknięcie wykrycia, poza tym, że nie ma dodatkowego bezpieczeństwa przy użyciu innego portu.
Jeśli tylko ograniczony zasięg IP może uzyskać dostęp do portu, oznacza to, że jesteś już „pod radarem”, więc nie widzę dobrego powodu, aby używać innego portu.
Aktualnie tak. Aby użyć innego przykładu, administrator laboratorium mojego uniwersytetu w Linuksie zmienił port SSH z 22 na pewną niejasną wartość. Poinformował, że sieć spadła z około 10.000 pingów / ataków dziennie do około 1 lub 2 miesięcznie. Oczywiście, jeśli już nie cierpisz z powodu tego rodzaju ataku, być może nie jest to warte wysiłku w większości przypadków. Mimo to, zmieniając dyskretny port alternatywny, zapobiegasz atakom szerokiej sondy i temu podobnych.
Myślę, że jest to dwuczęściowy problem.
1) Oprogramowanie do skanowania wspólnych portów może najpierw wypróbować wspólne porty, ale nic nie ogranicza tego przed wypróbowaniem wszystkich portów i musisz założyć, że będzie w stanie wydrukować protokół po znalezieniu otwartego portu .
2) Kiedy dzieje się bardziej agresywne skanowanie portów, musisz być w stanie je wykryć i zrobić coś z tą wiedzą (np. Fail2ban itp.)
Twój administrator proponuje (1), zapytaj, jakie ma pomysły na temat (2).
Bezpieczeństwo przez zaciemnienie wcale nie jest bezpieczeństwem.
Edycja: znowu niektórzy twierdzą, że tak ! Osobiście będę nadal przyjmować mój pierwotny punkt.
Zmiana portu zmusi ich do wykonania skanowania. Kiedy używasz narzędzia bezpieczeństwa, takiego jak snort, z kranami sieciowymi lub SPAN, wtedy coś w rodzaju skanowania portu twojego serwera staje się oczywiste. Ktoś legalnie łączący się z serwerem SQL na domyślnym porcie nie jest tak oczywisty.
Zgadzam się, że najlepszym podejściem nie jest bezpieczeństwo przez zaciemnienie. Jednak zmiana domyślnego portu we wszystkich aplikacjach, gdy jest to możliwe, jest częścią nadrzędnej, głębszej strategii, która obejmuje działania czerwonego zespołu, zespoły monitorujące bezpieczeństwo sieci oraz całe prawidłowe oprzyrządowanie, zainstalowane, dojrzałe i zrozumiałe dla ci, którzy go używają.
Kiedy masz wszystkie te rzeczy, intruz w twoim systemie wyróżnia się jak obolały kciuk. Podsumowując - jeśli ktoś myśli, że może poprawić bezpieczeństwo swoich systemów, zaznaczając kilka elementów na liście, jest w błędzie. Jeśli nie potrafią wyjaśnić, dlaczego potrzebują zmiany portu, bez żadnych wątpliwości, nie należą do roli kogoś, kto każe ci zmienić port.
Kiedy aplikacja łączy się z MS SQL przez TCPIP, pierwsza część konwersacji odbywa się 1433 z domyślną instancją bez nazwy - nie mniej ważne jest deseminacja numerów portów, z którymi komunikują się instancje. Wszelkie zapory ogniowe powinny być skonfigurowane w następujący sposób: a) przepuść to do odpowiednich zakresów ip, B) ustalone numery portów, których mogą używać dowolne nazwane instancje. Powinny one zostać skonfigurowane w menedżerze konfiguracji SQL jako naprawione. Możesz komunikować się z dowolną instancją przy użyciu (adres IP 192.168.22.55): (numer portu 12345) w ciągu połączenia. Jeśli usługa przeglądarki SQL nie jest włączona, 1433 nie zapewni wstępnej konwersacji. Jeśli używasz uwierzytelniania NT, niewiele możesz zyskać. Jeśli korzystasz z uwierzytelniania SQL, możesz zdobyć niewielką kwotę.