Come Proteggere il Suo Database SQL Server da Attacchi MITM con DataSunrise
1 Che Cos’è il MITM?
Quando un client si connette a un server tramite un canale protetto, c’è il rischio che una terza parte si connetta tra di loro con la capacità di ascoltare e interferire con le comunicazioni. Gli attacchi di rete lanciati tramite tale terza parte sono chiamati Man in the middle (MITM) attacks. Ci sono molti modi per effettuare un tale attacco, ma il principio di base è di far connettere segretamente il client al server dell’attaccante.
2 Come proteggersi dagli attacchi MITM?
Il metodo principale di protezione contro gli attacchi MITM è l’analisi dell’infrastruttura di rete al momento della connessione al server e il rilevamento di parametri sospetti che non sono tipici per la connessione a un certo server. Se si utilizza il protocollo SSL per la protezione, un client può controllare il certificato del server durante l’handshake. Un certificato può avere molti parametri, scambiati tra il client e il server durante l’autenticazione. Pratica standard per l’SSL è terminare immediatamente una connessione se una delle parti accetta un parametro (Nome Directory, DNS, Email, GUID, IP, UPN, URL e qualsiasi altro) che non è pertinente ai parametri del suo ambiente. Ma anche tale controllo del certificato non può garantire piena sicurezza, poiché l’infrastruttura del client al momento dell’attacco può essere modificata significativamente per superare il controllo. Ecco perché vengono spesso utilizzati metodi aggiuntivi di validazione del certificato. Uno di questi metodi è la firma di un certificato da parte di un’autorità di fiducia. Si ritiene che sia impossibile falsificare una tale firma, e ogni client può verificare la sua autenticità. Ecco perché qualsiasi certificato firmato da un’autorità speciale potrebbe essere accettato come più o meno sicuro, a seconda dell’autorità dell’emittente.
3 Protezione contro MITM in MS SQL Server
Il controllo del certificato è facoltativo in MS SQL, ma è abilitato di default. I due principali parametri che partecipano a un controllo del certificato sono la data di scadenza del certificato e il nome dell’host per cui il certificato è stato emesso (Nome Comune). Se un certificato è scaduto, o non è stato emesso per l’host di un server con cui è stata stabilita una connessione, la connessione verrebbe immediatamente terminata con una notifica all’utente. Nel caso in cui un’autorità di certificazione sia coinvolta in un controllo aggiuntivo dei certificati, il client verificherà la sua firma. In tal caso, ci dovrebbe essere un certificato radice di questa autorità nel deposito dei certificati. Molti sistemi operativi moderni includono set di certificati radice pre-costruiti delle autorità più affidabili, ed è per questo che, quando si seleziona un’autorità di certificazione per firmare un certificato aziendale, sarebbe saggio selezionare uno dalla lista.
Nel moderno SSMS, c’è una casella di controllo aggiuntiva «Trust server certificate» nella pagina di connessione del server. Viene utilizzata per controllare il certificato del server. Quando ci si connette a un server tramite ODBC, c’è un parametro aggiuntivo, “TrustServerCertificate”, nella stringa di connessione. Il valore “Yes” disabilita il controllo e “no” lo abilita.
4 Certificati in DataSunrise
Il proxy di DataSunrise è di fiducia, ma, tuttavia, è una terza parte della connessione, per questo motivo tutti i mezzi di protezione del client contro il MITM sarebbero attivati al momento della connessione con un tale proxy.
In DataSunrise, ogni istanza di database opera con un set di chiavi private e un certificato. Dal punto di vista del client, questo set appartiene al server, ma in generale, queste chiavi non sono associate al server finale che serve il proxy di DataSunrise in alcun modo. È questo certificato che un client controllerà se la protezione contro il MITM è attivata.
5 Possibili configurazioni di DataSunrise inclusive della protezione contro MITM
Per fornire un livello di protezione simile alla connessione diretta e alla connessione proxy, è necessario configurare correttamente DataSunrise e gli host del client. Potrebbero esserci diverse opzioni di configurazione.
Un set di chiavi e un certificato di default forniscono una protezione minima. Non è garantito che il certificato di default corrisponda al CN=DataSunrise Database Security Suite hostname. Ecco perché la prima cosa che Lei dovrebbe fare per proteggere una connessione è generare un nuovo set di chiavi e un certificato.
Un set di base di chiavi e un certificato sono inclusi nel file proxy.pem. È questo file che dovrebbe essere sostituito.
5.1 Caso generale
Questo è il caso più semplice, quando un amministratore ha solo un’istanza di DataSunrise a disposizione e un solo server MS SQL. E c’è un insieme limitato e stabilito di client che possono accedere ai server forniti tramite DataSunrise. Questo caso comprende due opzioni:
5.1.1 Generazione di proxy.pem (certificato autofirmato)
È il metodo più semplice per generare nuove chiavi. Creare un file proxy.cfg (“commonName” dovrebbe includere un nome reale dell’host di DataSunrise):
[req]
distinguished_name = req_distinguished_name
prompt = no
[req_distinguished_name]
countryName = US
stateOrProvinceName = Washington
localityName = Seattle
organizationName = Sunrise
organizationalUnitName = IT
commonName = wmserver.db.local
emailAddress = [email protected] Eseguire il seguente file .bat nella cartella in cui si trova il file proxy.config:
SET RANDFILE=random
SET PASS=R0T3qSW2s0459koH54
openssl genrsa -des3 -passout pass:%PASS% -out key.pem 2048
openssl rsa -passin pass:%PASS% -in key.pem -out key.pem
openssl req -config proxy.cfg -new -key key.pem -out certificate.req
openssl req -sha384 -x509 -config proxy.cfg -days 365 -key key.pem -in certificate.req -out certificate.cer
openssl ecparam -genkey -name secp256r1 -out ec.pem
openssl dhparam -out dh.pem 1024
COPY certificate.cer+key.pem+dh.pem+ec.pem proxy.pem /b
DEL random certificate.req key.pem dh.pem ec.pem Dopo l’esecuzione dello script, dovremmo ottenere un file proxy.pem con una chiave RSA a 2048 bit, una chiave DH a 1024 bit, parametri EC con la curva “secp256r1” e un certificato emesso per 365 giorni con l’algoritmo di firma “sha384”.
Inoltre, ci dovrebbe essere generato un file certificate.cer che dovrebbe essere installato nel deposito dei certificati attendibili del client.
5.1.2 Installazione di un certificato e chiavi proxy tramite l’interfaccia utente
Se un utente possiede già un set di chiavi e un certificato, potrebbero essere installati tramite l’interfaccia web di DataSunrise.
Per impostare delle chiavi e un certificato per un proxy, eseguire le seguenti operazioni:
- Creare un Gruppo Chiave SSL con il tipo Client Side.
- Riempire questo gruppo con tutti i parametri necessari in codifica Base64: un certificato, una chiave privata, parametri DH, parametri EC
- Connettere questo gruppo a un’istanza selezionandolo dalla lista dei Gruppi Chiave
Entrambe le opzioni (5.1.1 e 5.1.2) richiedono che Lei riavvii il Core di DataSunrise dopo aver sostituito le chiavi e installi un certificato creato per DataSunrise nel deposito dei certificati attendibili lato client.
5.2 Diverse istanze di DataSunrise
La configurazione successiva è per più istanze di DataSunrise. Se vengono utilizzati i suggerimenti del caso generale descritto sopra, sarebbe necessario installare un intero set di certificati lato client e tenere d’occhio la loro applicabilità. Per evitare possibili errori, si possono firmare tutti i certificati con una singola autorità di certificazione. Ci sono anche due opzioni.
5.2.1 La propria autorità di certificazione
Questa opzione è per creare la propria autorità di certificazione senza dipendenze aggiuntive dal sistema operativo. L’autorità di un tale emittente di certificati sarebbe minima.
Preparare l’infrastruttura:
mkdir db
mkdir db\new
mkdir db\private
echo. 2>db\index
echo 01> ./db/serial
echo unique_subject = no> ./db/index.attr Riempire il file ca.cfg:
[req]
distinguished_name = req_distinguished_name
prompt = no
RANDFILE = ./db/private/.rand
[req_distinguished_name]
countryName = US
stateOrProvinceName = Washington
localityName = Seattle
organizationName = DataSunrise
organizationalUnitName = IT
commonName = DataSunrise
emailAddress = [email protected] Riempire il file proxy.cfg:
[req]
distinguished_name = req_distinguished_name
prompt = no
RANDFILE = ./db/private/.rand
[req_distinguished_name]
countryName = US
stateOrProvinceName = Washington
localityName = Seattle
organizationName = Sunrise
organizationalUnitName = IT
commonName = wmserver.db.local
emailAddress = [email protected]
[ca]
default_ca = CA_default
[CA_default]
dir = ./db # top dir
database = $dir/index # index file.
new_certs_dir = $dir/new # new certs dir
certificate = $dir/ca.cer # The CA cert
serial = $dir/serial # serial no file
private_key = $dir/private/ca.pem # CA private key
RANDFILE = $dir/private/.rand # random number file
default_days = 365 # how long to certify for
default_crl_days = 30 # how long before next CRL
default_md = sha384
policy = policy_any # default policy
email_in_dn = no # Don't add the email into cert DN
name_opt = ca_default # Subject name display option
cert_opt = ca_default # Certificate display option
#copy_extensions = none # Don't copy extensions from request
[policy_any]
countryName = supplied
stateOrProvinceName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional Generare un certificato radice ./db/ca.cer e una chiave ./db/private/ca.pem. Questo certificato (la sua chiave) verrà utilizzato per firmare tutti i futuri certificati. Pertanto, ./db/ca.cer dovrebbe essere installato in un deposito certificato attendibile di tutti i client che verificheranno i certificati DataSunrise:
./db/private/ca.pem:
SET RANDFILE=.\db\private\.rand
SET PASS=TxK7T88C27
openssl genrsa -des3 -passout pass:%PASS% -out .\db\private\ca.pem 2048
openssl rsa -passin pass:%PASS% -in .\db\private\ca.pem -out .\db\private\ca.pem
openssl req -new -x509 -days 3650 -key .\db\private\ca.pem -out .\db\ca.cer -config ca.cfg
openssl x509 -noout -text -in .\db\ca.cer Generare e firmare proxy.pem:
SET RANDFILE=.\db\private\.rand
SET /P serial=<.\db\serial
SET PASS=RTqSWs0koH
openssl genrsa -des3 -passout pass:%PASS% -out .\db\private\%serial%.pem 2048
openssl rsa -passin pass:%PASS% -in .\db\private\%serial%.pem -out .\db\private\%serial%.pem
openssl req -new -key .\db\private\%serial%.pem -nodes -config proxy.cfg -out .\db\private\%serial%.req
openssl ca -batch -config proxy.cfg -infiles .\db\private\%serial%.req
openssl ecparam -genkey -name secp256r1 -out .\db\private\%serial%.ec.pem
openssl dhparam -out .\db\private\%serial%.dh.pem 1024
COPY .\db\new\%serial%.pem+key.pem+.\db\new\%serial%.dh.pem+.\db\new\%serial%.ec.pem proxy.pem /b
MOVE .\db\new\%serial%.pem .\db\new\%serial%.cer I certificati creati saranno salvati nella cartella db\new\
Le chiavi generate e i pfx compressi (chiave e certificato) saranno salvati nella cartella db\private\
Esempio. Un set di chiavi numero “01”:
db\new\01.cer — Nuovo certificato db\private\01.pem — Nuova chiave privata RSA db\private\01.dh.pem — Nuovi parametri DH db\private\01.ec.pem — Nuovi parametri e chiave EC
Durante ogni generazione di proxy.pem verrà creato un nuovo set di chiavi. Corresponderà a un nuovo proxy.pem generato. Dopo la sostituzione di proxy.pem in DataSunrise, è necessario riavviare il Core affinché le modifiche abbiano effetto. Avendo un nuovo set di chiavi, è possibile utilizzare anche il metodo 5.1.2 per aggiungere le chiavi tramite l’interfaccia utente senza modificare il proxy.pem.
5.2.2 Esecuzione di una autorità di certificazione aziendale
Se è necessario proteggere diversi host client, o ci sono diversi host DataSunrise inclusi in una rete aziendale (dominio) o in diverse reti attendibili (foresta), sarebbe utile utilizzare i servizi di Active Directory Certificate. In questo caso, è possibile utilizzare certreq per generare un proxy.pem. Prendiamo un proxy.cfg descritto nel sottos. 5.1.1 e generiamo un proxy.pem (i comandi dovrebbero essere eseguiti come utente con privilegi sufficienti per emettere nuovi certificati o come amministratore di dominio):
SET RANDFILE=random
SET PASS=89RT90qSWs020koH12
openssl genrsa -des3 -passout pass:%PASS% -out key.pem 2048
openssl rsa -passin pass:%PASS% -in key.pem -out key.pem
openssl req -config proxy.cfg -new -key key.pem -out certificate.req
certreq -submit -attrib "CertificateTemplate:WebServer" certificate.req certificate.cer
openssl ecparam -genkey -name secp256r1 -out ec.pem
openssl dhparam -out dh.pem 1024
COPY certificate.cer+key.pem+dh.pem+ec.pem proxy.pem /b
DEL random certificate.req certreq visualizzerà un dialogo per selezionare un centro di certificazione aziendale che dovrebbe essere utilizzato per emettere un nuovo certificato. Di solito, c’è un solo centro in tale elenco:
Ma questo dipende dall’infrastruttura di dominio aziendale. Consultare il proprio amministratore, se necessario.
Installando il proxy.pem, non è richiesta alcuna configurazione aggiuntiva del client di rete, perché dopo l’installazione di AD CS, il certificato radice copre automaticamente tutti gli host del dominio/foresta.
Utilizzando un set di chiavi e un certificato (certificate.cer, key.pem, dh.pem, ec.pem), è possibile utilizzare anche il metodo descritto nel sottos. 5.1.2 per aggiungere chiavi tramite l’interfaccia web senza modificare il proxy.pem.
5.3 Molti client
Quando ha bisogno di applicare un certificato a un numero elevato di client, può utilizzare le politiche di gruppo. Rifersi alla seguente guida Microsoft: https://technet.microsoft.com/en-us/library/cc770315%28v=ws.10%29.aspx?f=255&MSPPError=-2147217396 (Deploy Certificates by Using Group Policy)
6 Conclusione
Utilizzando qualsiasi metodo descritto sopra, può ottenere un alto livello di sicurezza della connessione proxy, ma spetta a Lei scegliere il metodo che meglio si adatta alla Sua infrastruttura. Per assicurarsi la piena sicurezza per il Suo database SQL Server può utilizzare i seguenti strumenti di DataSunrise:
