Sql Server features affecting security

A number of security benchmarks (e.g. CIS v1.0.0, FedRAMP, ..) those days we are recommending to disable Microsoft Sql Server features such as remote access, contained database authentication, cross db ownership chaining, allow updates, .. unless we actually have a real requirement for those features.

The rationale is that disabling those features, we would shrink the surface attack area.

A first step we can take is to get a report of which features are actually enabled in our database systems. The following query will do the deed (per instance):

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

CREATE TABLE #Database ( [Name] VARCHAR(255), [Feature] VARCHAR(255) ) EXEC sp_MSforeachdb N' BEGIN INSERT INTO #Database SELECT ''?'' AS [Name], NAME AS [Feature] FROM sys.configurations WHERE NAME IN ( ''allow updates'', ''cross db ownership chaining'', ''contained database authentication'', ''remote access'') AND Cast(value AS INT) = 1 END ' SELECT * FROM #Database DROP TABLE #Database

What if we find out that some of those features affecting security is actually enabled?
Here is a query which will reconfigure all the databases in a given instance, disabling remote access, one of those features:. 

1 2 3 4 5 6 7

EXEC sp_MSforeachdb N' BEGIN EXEC sp_configure ''show advanced options'', 1 RECONFIGURE WITH OVERRIDE EXEC sp_configure ''remote access'', 0 RECONFIGURE EXEC sp_configure ''show advanced options'', 0 RECONFIGURE END '

As usual:

Caveat: generally, don't use the above or similar scripts in Production, as long as you don't understand and accept the consequences. 

Caveat: always read the message log.

Caveat: sp_MSforeachdb is undocumented, and AFAIK unsupported.

Caveat: the code above is provided "as is", without warranty of any kind, express or implied, including but not limited to the warranties of merchantability, fitness for a particular purpose and noninfringement. in no event shall the author be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the software or the use or other dealings in the code above.

Simplify and Shrink

The following scripts sets the non system databases to simple recovery model, and shrinks the related log files:

EXEC sp_MSforeachdb N'IF DatabasePropertyEx(''?'', ''Recovery'')=''FULL''
    and   DatabasePropertyEx(''?'', ''Status'')=''ONLINE''
    and ''?'' not in (''tempdb'') and ''?'' not in (''master'') and ''?'' not in (''model'') and ''?'' not in (''msdb'')
begin
  exec ('' print char(13) + char(10) + ''''Set recovery model to simple for '''' + ''''?'''';
 alter database [?] set recovery simple with NO_WAIT;'')
end'

EXEC sp_MSforeachdb N'IF DatabasePropertyEx(''?'', ''Status'')=''ONLINE''
    and ''?'' not in (''tempdb'') and ''?'' not in (''master'') and ''?'' not in (''model'') and ''?'' not in (''msdb'')
begin
 exec ('' use [?];
 declare @logFile varchar(128);
 select @logFile= mf.name from sys.master_files mf inner join sys.databases db on mf.database_id = db.database_id where type=1 and db.name = ''''?'''';
 print char(13) + char(10) + ''''Shrink ''''+ @logFile + '''' log file of ?'''';
 dbcc shrinkfile (@logFile , 0)
 '')
end'

Caveat: generally, don't use the above or similar scripts in Production, as long as you don't understand and accept the consequences. The Simple recovery model is usually fine in Test or Development environments, but again, it may not be appropriate in many scenarios.

Caveat: always read the message log.

Caveat: the second script assumption is that there is no more than 1 log file per database. If there are multiple log files per database, it would be more sensible to look at a solution which doesn't use sp_MSforeachdb.

Caveat: sp_MSforeachdb is undocumented, and AFAIK unsupported.

Caveat: the code above is provided "as is", without warranty of any kind, express or implied, including but not limited to the warranties of merchantability, fitness for a particular purpose and noninfringement. in no event shall the author be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the software or the use or other dealings in the code above.

Mysterious error using the sqloledb provider on x64

Do you get a mysterious error using the sqloledb provider on x64?

Are things like -2146824535, 0x800A0EA9, Unknown error, Provider is not specified and there is no designated default provider (while it is there and apparently well specified) and similar wasting your day, even do the connection seems to open perfectly on x86 and amazingly even on some x64 code, but not in some other?

Give a look at the exact format of the connection string. Give it an hard look.

In my case, the x86 format was as such:

     connectionString = _bstr_t("\
     Provider=sqloledb; \
     Data Source=") + server + _bstr_t(";\
     Initial Catalog=") + database + _bstr_t(";");

This was not working at all in x64, returning all the above. Changing it in the following, made it working both for x64 and x86:

     connectionString = _bstr_t("Provider=sqloledb; \
     Data Source=") + server + _bstr_t(";\
     Initial Catalog=") + database + _bstr_t(";");

The difference was basically 6 blank spaces, if you don't count the starting escape.

Amazing, isn't?

A quando stipendi da 120 mila Euro annui in Sicilia?

Lavoro in Inghilterra, in un paesino di poco meno di 60 mila abitanti. Qualche giorno fa durante la pause per il pranzo sono andato al locale ufficio delle poste per inviare una lettera per conto di mia moglie, e mentre tornavo in ufficio ho attraversato una zona dove vi sono diverse agenzie per la ricerca di lavoro. Una delle agenzie aveva diverse offerte per il settore in cui lavoro, quello delle tecnologie dell'informazione, per retribuzioni che andavano da 16 mila Sterline lorde (se ricordo bene per un primo impiego per lavorare con un programma gestionale molto usato, SAP) in su. La media delle retribuzioni offerte sui volantini in quella vetrino era intorno alle 40-45 mila Sterline lorde annue.

Mi ha colpito molto l'offerta più alta, 100 mila Sterline annue lorde (equivalenti al cambio odierno a 120 mila Euro annui lordi) per andare a lavorare come amministratore di database (DBA) su tecnologia Microsoft Sql Server, con esperienza in ambienti ad elevate prestazioni (la lista dei requisiti aggiuntivi non era comunque lunghissima, anzi).

In realtà, anche se oggi lavoro con altre tante altre tecnologie e soprattutto a fare altro, ho parecchia esperienza con
quella particolare tecnologia, e la gran maggioranza dei requisiti per quella posizione li avrei, e conosco abbastanza bene il mercato Britannico per quella posizione, e so che mediamente per le posizioni da permanent su Microsoft Sql Server le retribuzioni vanno da circa 30 mila sterline per i meno esperti a circa 50 mila sterline per i più esperti, per cui leggere di 100 mila Sterline mi ha colpito abbastanza.

Ho quindi cercato su Internet il sito dell'agenzia, ed ho trovato l'annuncio.

Nell'annuncio si nota subito che in realtà le 100 mila Sterline sono il limite massimo, l'offerta retributiva parte da 50 mila Sterline fino ad un massimo di 100 mila Sterline. Sempre un ottimo stipendio, per carità, ma almeno più in linea con il resto del mercato (Britannico, di quello Italiano o peggio Siciliano meglio non parlarne!), almeno il limite inferiore.

La cosa che però non avevo notato nel volantino sulla vetrina, e che invece mi ha colpito veramente di più alla fine, è stata scoprire che il luogo di lavoro per la posizione è Malta.

Confesso di non conoscere per nulla il mercato del lavoro Maltese, ma mi ha sorpreso veramente leggere un'offerta di lavoro con una retribuzione praticamente allo stesso livello di quelle Britanniche o comunque del nord Europa in un paese che sostanzialmente è a pochi chilometri di distanza dalle coste siciliane.

E mi chiedo: perché i Maltesi riescono ad offrire retribuzioni comparabili a quelle dei paesi più sviluppati in ambito internazionale, ed i Siciliani no? Qual'è la differenza?

L'unica risposta che mi sono dato è che i Maltesi non fanno parte della Repubblica Italiana.

Non che a far parte della Repubblica Italiana ci si perda in ogni caso, anzi, ci sono aree del paese che hanno giovato tantissimo dall'unificazione, ad esempio il Veneto e gran parte della cosiddetta Padania, aree poverissime per secoli fino ad oltre la metà del XIX secolo, ed in cui le traccia della povertà ataviche sono rimaste fino a pochi decenni fa, pensiamo ad esempio alla piaga della pellagra, ma a quanto pare alla Sicilia ed ai Siciliani non riesce proprio di far fruttare questa benedetta, o maledetta, dipende dai punti di vista, unità.

Ad ogni modo, se tra voi c'è qualche informatico, qualche ingegnere, magari qualche DBA, e lavorare ad una mezz'ora di aereo (ma forse saranno anche venti minuti) dalla Sicilia non vi scoraggia, ora sapete che magari uno sguardo a Malta glielo potreste dare, non soltanto dal punto di vista turistico, ma anche lavorativo!