Quali minacce alla sicurezza rappresentano l'account SA e altri nomi di account noti alla sicurezza?

Un nome account noto come sa rappresenta una minaccia per la sicurezza del database? Quando si utilizza l'autenticazione di Windows su SQL Server impone lo stesso criterio password (se è stato impostato per dire il blocco dell'account dopo 5 volte)?

Un nome account noto come sa rappresenta una minaccia per la sicurezza del database?

Un account utente "god" con un nome noto è generalmente considerato un'idea peggiore di un utente god con un nome meno noto. Rende gli attacchi di forza bruta un po 'più facili poiché l'attaccante deve solo indovinare la password e non il nome utente e la password.

Anche avere un utente divino può essere pericoloso. In genere è meglio avere utenti specifici con diritti specifici per ciò che devono fare. Questo tipo di sicurezza basata sui privilegi è più facile da implementare da zero che non è necessario adattarlo successivamente al proprio ambiente.

La disabilitazione di sa e il conferimento di specifici diritti di amministratore specifici per gli utenti, come necessario in SQL Server, è essenzialmente la stessa raccomandazione della disabilitazione roote della distribuzione dei diritti di amministratore necessari sudoin Linux e simili. Puoi sempre riattivare sauna volta connesso direttamente alla macchina con privilegi adeguati se qualcosa va storto e finisci per perdere tutti i diritti di cui gli utenti hanno bisogno per operare (e risolvere il problema) esattamente come puoi progettare l'accesso root a un Linux box se hai accesso fisico alla box - quindi disabilitare l'account non è un proiettile magico (ma una volta che un attaccante ha accesso fisico alla tua macchina o accesso amministrativo completo tramite RDC o SSH, tutte le scommesse sono comunque disattivate).

Quando si utilizza l'autenticazione di Windows su SQL Server impone lo stesso criterio password (se è stato impostato per dire il blocco dell'account dopo 5 volte)?

Quando si utilizza l'autenticazione integrata di Windows, il server SQL non ha alcun controllo sui blocchi degli account e simili: associa semplicemente un utente Windows a un utente SQL e chiede al sistema operativo di confermare che l'utente ha fornito le credenziali appropriate. Per gli utenti umani interattivi ciò significa che si verificherebbe un blocco quando l'utente tentava di autenticarsi con Windows, non quando si accedeva a SQL Server.

Non è una cattiva idea farlo in modo che l'utente amministratore predefinito (admin / root / postgres / sa / etc) non esista effettivamente nel tuo sistema. Puoi sempre creare un account privilegiato con un nome diverso.

Se non altro, le persone che cercano di sfruttare il tuo sistema non sono abbastanza facili come se stessero lavorando alla cieca (ad esempio, l'iniezione sql senza avere una shell interattiva né essere in grado di vedere l'output diretto dai loro comandi)

Per quanto riguarda i blocchi degli account: se qualcuno è riuscito ad arrivare abbastanza lontano da riuscire persino a tentare di accedere al tuo computer, a meno che tu non autorizzi specificamente l'accesso diretto da parte degli utenti, hai già perso la battaglia. Personalmente, non sono a favore dei blocchi per la maggior parte, perché dà a qualcuno la possibilità di creare una negazione del servizio se riescono a ottenere il nome di uno dei tuoi utenti. (e farli bloccare il superutente? non è divertente).

Consiglierei di esaminare i benchmark CIS ... non li hanno per tutti i database, ma hanno consigli per Oracle, MS SQL, DB2 e MySQL. Se stai eseguendo qualcos'altro, vale comunque la pena esaminare il genere generale di cose che raccomandano.

Non ho visto nessun altro menzionarlo, quindi lo aggiungerò. Con SQL Server 2005+ se il tuo server fa parte di un dominio e il dominio dispone di un criterio password, puoi abilitare il criterio password da applicare agli accessi SQL. Ciò include i requisiti di complessità della password e la possibilità di forzare le modifiche della password all'accesso.

Si noti che ciò può a volte causare problemi con alcuni programmi di installazione software che non sono stati aggiornati per funzionare con SQL 2005+ e creare accessi SQL con password non sicure.

Esistono due modalità di autenticazione utilizzate in SQL Server: autenticazione di Windows e modalità mista (abilita sia l'autenticazione di Windows sia l'autenticazione di SQL Server)

La prima modalità è meno vulnerabile agli attacchi di forza bruta poiché è probabile che l'attaccante si imbatta in un blocco di accesso (la funzione Politica di blocco dell'account) dopo un numero finito di tentativi di attacco. Ogni ambiente di produzione, se si utilizza la modalità di autenticazione di Windows, dovrebbe utilizzare la funzionalità dei criteri di blocco, poiché rende impossibili gli attacchi di forza bruta

Quando si tratta di vulnerabilità di attacco di forza bruta di autenticazione di SQL Server, la situazione non è così favorevole. L'autenticazione di SQL Server non ha funzionalità che consentono di rilevare quando il sistema è sottoposto a un attacco di forza bruta. Inoltre, SQL Server è molto reattivo quando si tratta di convalidare le credenziali di autenticazione di SQL Server. Può facilmente gestire tentativi di accesso ripetuti, aggressivi, a forza bruta senza prestazioni complessive negative che potrebbero indicare tali attacchi. Ciò significa che l'autenticazione di SQL Server è un obiettivo perfetto per il crack delle password tramite attacchi di forza bruta

Inoltre, i metodi di forza bruta si stanno evolvendo con ogni metodo di crittografia e complessità della password appena introdotto. Ad esempio, gli aggressori che usano le tabelle arcobaleno (le tabelle pre-calcolate per invertire i valori hash crittografici per ogni possibile combinazione di caratteri) possono facilmente e rapidamente decifrare qualsiasi password con hash

Per proteggere il tuo SQL Server da attacchi di forza bruta, dovresti considerare quanto segue:

• Non utilizzare la modalità di autenticazione di SQL Server: forzare l'attaccante a colpire il blocco di accesso tramite l'autenticazione di Windows
• Nel caso in cui sia necessario utilizzare la modalità di autenticazione di SQL Server, disabilitare o rimuovere il login SA, in questo modo l'attaccante deve indovinare e associare sia il nome utente che la password

L'account sa, quando abilitato, può fare qualsiasi cosa su SQL Server. Se un utente malintenzionato dovesse accedere a questo account, potrebbe fare qualsiasi cosa sull'istanza di SQL Server (e possibilmente sul sistema operativo host) che desidera.

La SA (e altri nomi di account ben noti) sono punti ben noti che gli hacker possono attaccare. Alcuni di quelli Oracle erano scarsamente documentati e quindi le password predefinite non venivano sempre modificate. Una volta ottenuto il controllo dell'account SA in SQL Server, controlli il server su cui è in esecuzione e puoi eseguire qualsiasi codice o installare tutto ciò che desideri. Nei miei giorni da cowboy, ricordo di non essere stato autorizzato (aveva bisogno di scartoffie che non avevo intenzione di compilare) per installare un controllo ActiveX su un server web che ospitava anche SQL Server, quindi ho usato xp_cmdshell per copiare e installare il controllo .