Jakie zagrożenia bezpieczeństwa stanowią dla konta SA i innych znanych nazw kont dla bezpieczeństwa?

Czy znana nazwa konta, np. Sa, stanowi zagrożenie dla bezpieczeństwa bazy danych? Czy podczas korzystania z uwierzytelniania systemu Windows w programie SQL Server nakłada się tę samą politykę haseł (jeśli ustawiono blokadę konta po 5 razy)?

Czy znana nazwa konta, np. Sa, stanowi zagrożenie dla bezpieczeństwa bazy danych?

„Boskie” konto użytkownika o znanej nazwie jest ogólnie uważane za gorszy pomysł niż boski użytkownik o mniej znanej nazwie. To sprawia, że ​​ataki siłowe są nieco łatwiejsze, ponieważ atakujący musi tylko odgadnąć hasło, a nie nazwę użytkownika i hasło.

Również posiadanie boga użytkownika może być niebezpieczne. Zasadniczo lepiej jest mieć określonych użytkowników posiadających określone prawa do tego, co muszą zrobić. Tego rodzaju zabezpieczenia oparte na uprawnieniach są łatwiejsze do wdrożenia od zera niż później do późniejszego doposażenia w środowisko.

Wyłączenie sa i nadanie określonym użytkownikom określonych uprawnień administratora w razie potrzeby na serwerze SQL jest zasadniczo takim samym zaleceniem, jak wyłączenie rooti przekazywanie uprawnień administratora w razie potrzeby za pośrednictwem sudoLinuxa i podobnych. Zawsze możesz ponownie włączyć saraz podłączony bezpośrednio do komputera z odpowiednimi uprawnieniami, jeśli coś pójdzie nie tak i w końcu zrzucisz wszystkie prawa, których użytkownicy potrzebują do działania (i naprawienia problemu) tak samo, jak możesz zmodyfikować dostęp roota do systemu Linux pole, jeśli masz fizyczny dostęp do pudełka - więc wyłączenie konta nie jest magiczną kulą (ale gdy atakujący ma fizyczny dostęp do twojej maszyny lub pełny dostęp administracyjny za pośrednictwem RDC lub SSH, wszystkie zakłady i tak są wyłączone).

Czy podczas korzystania z uwierzytelniania systemu Windows w programie SQL Server nakłada się tę samą politykę haseł (jeśli ustawiono blokadę konta po 5 razy)?

Podczas korzystania z zintegrowanego uwierzytelniania systemu Windows serwer SQL nie ma kontroli nad blokadami kont i tym podobne - po prostu mapuje użytkownika systemu Windows na użytkownika SQL i prosi system operacyjny o potwierdzenie, że użytkownik podał odpowiednie poświadczenia. Dla interaktywnych użytkowników oznacza to, że nastąpi jakakolwiek blokada, gdy użytkownik będzie próbował uwierzytelnić się w systemie Windows, a nie podczas logowania do SQL Server.

Nie jest to zły pomysł, aby domyślny użytkownik admin (admin / root / postgres / sa / etc) nie istniał w twoim systemie. Zawsze możesz utworzyć konto uprzywilejowane pod inną nazwą.

Co więcej, ludzie próbujący wykorzystać twój system nie mają tak łatwego czasu, jak gdyby pracowali w ciemno (np. Wstrzykiwanie sql bez interaktywnej powłoki lub nie widząc bezpośredniego wyniku swoich poleceń)

Jeśli chodzi o blokowanie kont - jeśli komuś udało się dostać wystarczająco daleko, aby móc nawet zalogować się na twoim komputerze, chyba że zezwolisz na bezpośrednie logowanie użytkowników, przegrałeś już bitwę. Osobiście nie jestem zwolennikiem blokowania, ponieważ daje komuś możliwość odmowy usługi, jeśli uda mu się uzyskać nazwę któregoś z twoich użytkowników. (a ich zablokowanie superużytkownika? nie jest zabawne).

Polecam przejrzeć Benchmarki CIS ... nie mają ich dla każdej bazy danych, ale mają rekomendacje dla Oracle, MS SQL, DB2 i MySQL. Jeśli prowadzisz coś innego, nadal warto przyjrzeć się ogólnym zaleceniom.

Nie widziałem, żeby ktokolwiek o tym wspominał, więc dodam to. W przypadku SQL Server 2005+, jeśli serwer jest częścią domeny, a domena ma zasady haseł, można włączyć wymuszanie zasad haseł podczas logowania SQL. Obejmuje to wymagania dotyczące złożoności hasła oraz możliwość wymuszenia zmiany hasła przy logowaniu.

Należy pamiętać, że może to czasami powodować problemy z niektórymi instalatorami oprogramowania, które nie zostały zaktualizowane do pracy z SQL 2005+ i tworzenia loginów SQL z niepewnymi hasłami.

Istnieją dwa tryby uwierzytelniania używane w SQL Server: uwierzytelnianie Windows i tryb mieszany (włącza zarówno uwierzytelnianie Windows, jak i uwierzytelnianie SQL Server)

Pierwszy tryb jest mniej podatny na ataki typu „brute force”, ponieważ atakujący najprawdopodobniej wpadnie w blokadę logowania (funkcja zasad blokady konta) po skończonej liczbie prób ataku. Każde środowisko produkcyjne, jeśli korzysta z trybu uwierzytelniania systemu Windows, powinno korzystać z funkcji zasad blokowania, ponieważ uniemożliwia ataki siłowe

Jeśli chodzi o podatność na ataki typu brute-force uwierzytelniania SQL Server, sytuacja nie jest tak korzystna. Uwierzytelnianie programu SQL Server nie ma funkcji umożliwiających wykrycie, gdy system jest atakowany metodą brute-force. Ponadto program SQL Server bardzo szybko reaguje na sprawdzanie poprawności poświadczeń uwierzytelniania programu SQL Server. Bez problemu radzi sobie z powtarzającymi się, agresywnymi próbami logowania z użyciem brutalnej siły bez negatywnej ogólnej wydajności, która może wskazywać na takie ataki. Oznacza to, że uwierzytelnianie programu SQL Server jest idealnym celem do łamania haseł za pomocą ataków siłowych

Ponadto metody brute-force ewoluują wraz z każdą nowo wprowadzoną metodą szyfrowania i złożoności hasła. Na przykład osoby atakujące, które używają tęczowych tabel (wstępnie obliczone tabele do odwracania kryptograficznych wartości skrótu dla każdej możliwej kombinacji znaków) mogą łatwo i szybko złamać dowolne haszowane hasło

Aby chronić SQL Server przed atakami typu brute-force, należy wziąć pod uwagę następujące kwestie:

• Nie używaj trybu uwierzytelniania programu SQL Server - zmuś atakującego do zablokowania logowania za pomocą uwierzytelniania systemu Windows
• Jeśli chcesz użyć trybu uwierzytelniania programu SQL Server, wyłącz lub usuń login SA - w ten sposób atakujący musi odgadnąć i sparować zarówno nazwę użytkownika, jak i hasło

Konto sa, gdy jest włączone, może robić wszystko na serwerze SQL. Jeśli osoba atakująca miałaby dostać się na to konto, mogłaby zrobić wszystko na instancji programu SQL Server (i ewentualnie systemie operacyjnym hosta), co chciała.

SA (i inne znane nazwy kont) to znane punkty, które hakerzy mogą atakować. Niektóre z nich były słabo udokumentowane, dlatego domyślne hasła nie zawsze były zmieniane. Po uzyskaniu kontroli nad kontem SA w programie SQL Server kontrolujesz serwer, na którym działa, i możesz uruchomić dowolny kod lub zainstalować cokolwiek zechcesz. W moich bardziej kowbojskich czasach pamiętam, że nie zezwalałem (wymagało to papierkowej roboty, której nie zamierzałem wypełnić), aby zainstalować formant ActiveX na serwerze WWW, który również hostował SQL Server - więc użyłem xp_cmdshell, aby skopiować i zainstalować formant .