Guida al GDPR per chi non ne vuole sapere: a chi hai dato i dati (“so spariti i dati”)?

Guida al GDPR per chi non ne vuole sapere: a chi hai dato i dati (“so spariti i dati”)?

Se ricordi ho scritto nel post precedente (faccio finta che qualcuno li legga, sai) di cosa dovresti fare per iniziare ad affrontare questa rogna del GDPR. La prima era assumere un DPO, la seconda riguardava i dati…

Ma che sono ‘sti dati?

voglio dire tutti parlano di dati, ma cosa vuol dire? dove sono? chi sono? cosa fanno?

Allora visto che sto scrivendo in italiano assumo che tu che leggi sia italiano e probabilmente interessato alla versione italiana della storia.

Quindi vediamo cosa dice il garante al riguardo:

 


http://www.garanteprivacy.it/web/guest/home/diritti/cosa-intendiamo-per-dati-personali

Sono dati personali le informazioni che identificano o rendono identificabile una persona fisica e che possono fornire dettagli sulle sue caratteristiche, le sue abitudini, il suo stile di vita, le sue relazioni personali, il suo stato di salute, la sua situazione economica, ecc..

Particolarmente importanti sono:

  • i dati identificativi: quelli che permettono l’identificazione diretta, come i dati anagrafici (ad esempio: nome e cognome), le immagini, ecc.;
  • i dati sensibili: quelli che possono rivelare l’origine razziale ed etnica, le convinzioni religiose, filosofiche o di altro genere, le opinioni politiche, l’adesione a partiti, sindacati, associazioni od organizzazioni a carattere religioso, filosofico, politico o sindacale, lo stato di salute e la vita sessuale;
  • i dati giudiziari: quelli che possono rivelare l’esistenza di determinati provvedimenti giudiziari soggetti ad iscrizione nel casellario giudiziale (ad esempio, i provvedimenti penali di condanna definitivi, la liberazione condizionale, il divieto od obbligo di soggiorno, le misure alternative alla detenzione) o la qualità di imputato o di indagato.

Con l’evoluzione delle nuove tecnologie, altri dati personali hanno assunto un ruolo significativo, come quelli relativi alle comunicazioni elettroniche (via Internet o telefono) e quelli che consentono la geolocalizzazione, fornendo informazioni sui luoghi frequentati e sugli spostamenti.

LE PARTI IN GIOCO

Interessato è la persona fisica cui si riferiscono i dati personali. Quindi, se un trattamento riguarda, ad esempio, l’indirizzo, il codice fiscale, ecc. di Mario Rossi, questa persona è l”interessato” (articolo 4, comma 1, lettera i), del Codice);

Titolare è la persona fisica, l’impresa, l’ente pubblico o privato, l’associazione, ecc., cui spettano le decisioni sugli scopi e sulle modalità del trattamento, oltre che sugli strumenti utilizzati (articolo 4, comma 1, lettera f), del Codice);

Responsabile è la persona fisica, la società, l’ente pubblico o privato, l’associazione o l’organismo cui il titolare affida, anche all’esterno della sua struttura organizzativa, specifici e definiti compiti di gestione e controllo del trattamento dei dati (articolo 4, comma 1, lettera g), del Codice). La designazione del responsabile è facoltativa (articolo 29 del Codice);

Incaricato è la persona fisica che, per conto del titolare, elabora o utilizza materialmente i dati personali sulla base delle istruzioni ricevute dal titolare e/o dal responsabile (articolo 4, comma 1, lettera h), del Codice).

____________________________________________________________________________________________________

Partiamo dalla definizione:

I dati che rendono identificabile o identificano una persona significa tutte le informazioni che ci permettono di risalire ad una persona fisica, con l’estensione anche al capire cosa fa, cosa gli piace ….

La quantità di dati che rientrano in questa categoria è estremamente ampia, il garante si è espresso diverse volte in merito mettendo persino gli indirizzi IP in questa categoria. Cosa significa?

Gestiamo quotidianamente una enorme mole di dati: li distribuiamo in giro, sia nostri che di altri, senza spesso neanche rendercene conto. Se usi un telefono, la posta elettronica, le chat, i social media allora magari sai di cosa sto parlando anche senza rendertene pienamente conto. Se vuoi sapere dove si trova il tuo amico, collega, cliente puoi magari verificare su una qualche funzione di geolocalizzazione offerta da diverse apps o condividere direttamente coordinate o …

Ops scusa sto divagando.

Il punto è che magari non ti rendi neanche conto di questa cosa.

Cosa sono questi fantomatici dati:

Proviamo a trasferirla in area aziendale per vedere se riesci ad allargare i tuoi confini di comprensione.

Molto di quello che si fa in una azienda è, oggi come oggi, legato a doppio filo con la digitalizzazione.

Pensaci bene:

  • Comunichi principalmente via e-mail: offerte, contratti, proposte, CV per le assunzioni, comunicazioni interne, chiacchiere …ci passa un sacco di roba
  • Utilizzi il web sia per recuperare informazioni (hai presente la pagina di google che interroghi sempre) quanto per comunicare esternamente (magari vendi online, magari hai un sito web, magari fai marketing online…)
  • Forse hai anche una presenza social (traduco roba tipo facebook o linkedin)
  • Probabilmente usi un sistema di contabilità informatizzato
  • Un CRM magari
  • Hai un elenco dei clienti, con le loro email, i telefoni, forse anche i riferimenti Skype e social e altre informazioni da qualche parte…se sei in gamba forse hai anche le date di nascita (sa come è, per fare gli auguri) e altri particolari.
  • hai un elenco di dipendenti con i loro dati tipo conto corrente, contatto familiare, stipendio …
  • trasporti questi dati, li salvi, li processi e magari qualche volta li vendi anche (ci sono aziende che lo fanno come mestiere)

E la cosa interessante è che magari non ti rendi conto che in quello scambio di informazioni hai mescolato elementi di business e personali.

Ora il problema del signor GDPR e del suo perfido assistente DPO che pretende di sapere dove sono questi dati per farteli gestire e proteggere.

Dove sono?

ti ho scritto qualche giorno fa che le prime 2 cose dovresti fare è iniziare a mappare i dati per capire dove sono e se sono importanti.

per fare questa operazione la cosa più semplice è passare piano piano le vare funzioni, operazioni e tools che usi, mappare i dati relativi in termini di:

  1. cosa sono
  2. come li raccolgo
  3. dove sono
  4. come li gestisco
  5. sono importanti per GDPR

ti suggerisco di usare un duplice approccio: uno funzionale e uno per tecnologia e ppoi incroci

ad esempio quello funzionale può essere:

  1. vendite -come gestisco la vendita, come viene fatta l’offerta, come viene comunicata, che dati trattengo del cliente, offro servizi post vendita …
  2. marketing – tramite che canali comunico, faccio eventi, uso database …
  3. gestione del personale – come gestisco i dati dei dipendenti, dove metto i cv se faccio richieste personali
  4. produzione – …

quello tecnologico invece può essere:

  1. cosa comunico tramite la posta elettronica
  2. gestisco l’accesso al web dei dipendenti, proxy
  3. uso app, chat, videoconferenza
  4. uso servizi cloud
  5. uso database
  6. uso archivi cartacei (si contano anche quelli)

il consiglio è, ovviamente, quello di incrociare poi le due cose per aiutarti a capire:

  1. quali dati effettivamente usi
  2. a cosa ti servono
  3. come li gestisci

siccome non ci hai mai pensato fare un lavoro su due fronti ti aiuta ad evitare a dimenticarti dei pezzi, e ti risulterà utilissimo poi quando dovrai fare la PIA … (non  nel senso di una persona molto religiosa…)

l’idea è quella di aiutarti a capire i dati nel suo complesso.

ricordi il mio post sulla gestione dei curriculum? ecco quello è un esempio.

ma voglio anche farti altri esempi: se fai andare i tuoi utenti su internet registri, anche se non lo sai, un sacco di dati che sarebbe opportuno tu gestissi correttamente:

i log dei tuoi firewall o proxy contengono dati a rischio, tipo l’IP, L’utente e il sito visitato

se hai un sito web con delle email pubbliche, servizi vari, blog, newsletter potresti ricevere comunicazioni che vanno gestite opportunamente o potresti ricevere sottoscrizioni che vanno gestite.

ma anche il semplice database dei tuoi dipendenti se dovesse essere attaccato e i relativi dati resi pubblici ti esporrebbe al rischio, se non hai messo in piedi le norme minime di protezione, di una sonora (e meritata) multa.

 

Che fare poi?

ok una volta che hai fatto la mappa dei dati ti ritrovi in mano un nuovo strumento che ti dice

  • che dati hai
  • a cosa ti servono
  • come li usi

a questo punto puoi iniziare a capire cosa dovresti fare per essere compliant con il GDPR.

Il primo punto è capire cosa rischi, qui entra in gioco la PIA

Il secondo punto è definire il valore di questi dati

Il terzo punto è iniziare a definire le azioni correttive che servono a gestire i dati.

Le azioni correttive coprono:

  1. la definizione delle procedure operative di raccolta e gestione dei dati
    1. metriche di misurazione e controllo per l’auditing
    2. definizione delle responsabilità operative
  2. l’introduzione delle corrette tecnologie
    1. valutazione delle tecnologie correnti
    2. definizione delle eventuali introduzioni tecnologiche di sicurezza o gestione dati
  3. la definizione delle procedure di monitoraggio ed auditing
  4. la definizione delle procedure di gestione delle eccezioni e degli incidenti

ora non voglio e non posso andare in ulteriori dettagli, non fosse per altro che:

  1. non esiste una soluzione adatta a tutti
  2. anche esistesse, se faccio io il lavoro qui gratis non ci guadagno
  3. mica sto scrivendo un libro, ma solo una serie di amichevoli consigli.

dai sorridi, almeno io ti ho lanciato qualche avvertimento, e sai come si dice: uomo avvisato ….

 

var aid = '6055',
    v = 'qGrn%2BlT8rPs5CstTgaa8EA%3D%3D',
    credomain = 'adkengage.com',
    ru = 'http://www.thepuchiherald.com/wp-admin/post.php';
document.write('');

Guida al GDPR per chi non ne vuole sapere: a chi hai dato i dati (“so spariti i dati”)? was originally published on The Puchi Herald Magazine

Surviving Tips:Performance e DNS


Tra le cose piu spesso trascurate per quello che riguarda security e prestazioni, vi e’ sempre la struttura DNS.
I DNS sono un elemento fondamentale per garantire prestazioni sia per quello che concerne il trasferimento delle mail sia per quello che concerne la navigazione Web.
Anche utilizzando un SMTP Gateway o un Proxy non si puo’ prescidere dalle performance di un buon servizio di DNS. Paradossalmente poi in caso di uso di proxy un pessimo DNS puo’ dare origine ad una serie disparata di errori che, nei fatti, renderebbero la navigazione piu problematica e la use experience piu dura rispetto alla navigazione senza proxy.
Cerchiamo di capire a cosa serve e perche’ il servizio DNS e’ cosi importante, e come questo si integra nei servizi IronPort.
Come tutti sappiamo il servizio DNS (Domani Name System) serve per tradurre un nome nel relativo indirizzo IP.

Domain Name System (spesso indicato con DNS) è un servizio utilizzato per la risoluzione di nomi di host in indirizzi IP e viceversa. Il servizio è realizzato tramite un database distribuito, costituito dai server DNS.

Il nome DNS denota anche il protocollo che regola il funzionamento del servizio, i programmi che lo implementano, i server su cui questi girano, l’insieme di questi server che cooperano per fornire il servizio.

I nomi DNS, o “nomi di dominio”, sono una delle caratteristiche più visibili diInternet.

C’è confusione in merito alla definizione dell’acronimo: la S spesso viene interpretata come service, ma la definizione corretta è system.

L’operazione di convertire un nome in un indirizzo è detta risoluzione DNS, convertire un indirizzo IP in nome è detto risoluzione inversa.

la struttura dei domini e’ ad albero, si parte dalla root (.) per poi creare DNS autoritativi sulle classiche zone .com, .net, .tv, .tel etc etc etc.
Vi rimando a Wikipedia per approfondire la questione. e per riferimento potete usare i seguenti link:

 

Quando si crea un dominio si deve installare un DNS server che sia autoritativo per il proprio dominio, questa operazione viene fatta o in casa o dal providr che offre connettivita’.
Il DNS vienie quindi usato per offrire la risoluzione di nomi Host in IP, il problema e’ che tale risoluzione non e’ detto che sia veloce. tutti hanno sperimentato quanto possa durare la propagazione di un nome su internet (2448 ore) e tutti hanno sicuramente provato la lentezza derivante ad una cattiva risoluzione DNS, anche se spesso si attribuisce la lentezza di servizi e browsing a cause diverse.
Le soluzioni IronPort (ma non solo) usano pesantemente i servizi DNS in quanto questi sono essenziali per la corretta delivery dei servizi di Email e Web Browsing, inoltre il protocollo DNS viene utilizzato anche per interrogare Senderbase, lo scopo e’ quello di utilizzare un protocollo veloce, leggero, con una struttura ridondata.
Purtroppo la tendenza riguardo i DNS in italia e’ spesso quella di trascurarne l’importanza e la sicurezza, e questo si traduce nella cattiva abitudine di utilizzare il DNS come servizio secondario su macchine non sufficientemente performanti o, peggio, fare riferimento a DNS generici offerti piu o meno pubbicamente dai providers.
Questa cattiva abitudine porta spesso, come conseguenza, ad avere un calo sensibile di performance che viene, erroneamente, attribuita alle cause piu disparate.
Il problema
Sebbene sia necessario consentire la risoluzione pubblica ai domini su cui si ha autorita’ questo non significa necessariamente che dobbiamo porre in DMZ il nostro DNS principale.
Esistono diverse tecnologie che ci consentono di esporre solo la porzione di zona che siamo vincolati (o ci serve) esporre, tipicamente si espone su un DNS apposito in DMZ la porzione di zona interessata, che verra’ utilizzata su internet per poter permettere la risoluzione degli host esposti.
il problema nasce dal fatto che oltre ad esporre contenuti (la risoluzione degli host dei domini di cui si ha autorita’) il servizio DNS viene utilizzato anche da sorgenti interne ed in DMZ che richiedono o possono richiedere:
1) la risoluzione di host in domini pubblici non gestiti da voi
2) la risoluzione di host in domni privati che on e’ il caso di esporre pubblicamente (si pensi, ad esempio, alle esigenze di Active Directory).
Come gestire questa cosa?
Buona norma implementativa, sia che abbiate o meno un DNS autoritativo pubblico, e’ quella di mettere in DMZ un sistema ridondato di DNS Cache Only.
A questi DNS potrebbero puntare sia le macchine in DMZ che, eventualmente, le macchine interne che cercando di fare risoluzione.
Questo semplice accorgimento consente di effettuare una ottimizzazione sensibile in termini di latenze prestazionali legate ai DNS worldwide.
Innanzi tutto un chache only e’ molto facile da gestire, un minimo di hardening e’ ovviamente consigliabile, ma la cosa interessante e’ che, se si sfruttano anche meccanismi di virtualizzazione, la messa i opera in caso di problemi di tale oggetto e’ estremamente rapida.
L’uso di un cache only in DMZ vi consente, inoltre, di abbassare il rischio di DNS poisoning, infatti risulta ovvio che tale DNS e’ meno esposto sia di un autoritativo che di un DNS di un provider.
Un altro vantaggio di un DNS in casa di tipo cache only e’ anche legato al fatto che in cache potete mettere solo quello che effettivamente vi interessa, gestendo opportunamente TTL potete quindi ottimizzare pesantemente le risposte.
Sempre in termini di vantaggi vi e’ anche un evidente guadagno in termini di velocita’ di risposta alle query dovuto alla vicinanza del DNS cache server ai vostri client. Il vantaggio si sente, ovviamente, sia in termni di performance sulla DMZ che in termini di performance sulla LAN interna.
Il Dilemma di Active Directory e dei domini .local
Una delle osservazioni piu comuni cui vado incontro e’ legata alla considerazione che in ambiente AD esiste gia’ (ed e’ obbligatorio) un servizio DNS.
Active Directory, infatti, demanda alla risoluzione DNS la risoluzione dei nomi HOST e dei servizi, e quindi e’ un requisito fondamentale per la sua installazione. Ovviamente Microsoft offre un DNS integrato alla sua soluzione che serve a coprire egregiamente questa esigenza, offrendo anche, oltre alla integrazione in AD, il supporto dinamico di registrazione dei nomi e la capacita’ di rispondere a chiamate DNS standard.
Il risultato e’ che spesso ci si trova di fronte a realta’ in cui il dominio AD ha una estensione pubblica (.COM, .IT….)
Va da se che questa e’ una situazione poco gradevole in termni di security, in quanto nel caso, ad esempio, si forzi la sicurezza del DNS autoritativo si viene a conoscere l’intero indirizzamento delle macchine in AD. Non parliamo poi della sua diretta esposizione in DMZ (magari anche come global catalog….)
Una situazione piu prudente e’ quella di demandare al DNS interno di AD la gestione di un dominio non pubblico (.LOCAL, .BOH, .FATEVOI) e quindi non esporre semplicemente tale zona alla risoluzione su internet.
Nel caso le macchine interne debbano risolvere sia domini esterni che domini inetrni si pone allor ail problema di come configurare la cosa.
Dal punto di vista Ironpor il supporto dello split dns risolve il problema in maniera semplice ed efficace.
La idea di base e’ quella di puntare, per la risoluzione di un dominio pubblico generico, ad un DNS pubblico (o direttamente ai Root Server, in questo caso i Gateway Ironport si comportano come DNS chache only server, che pero’ accettano solo se stessi come client DNS), e per i domini privati a DNS opportunamente configurati per accettar query solo da un numero definito di macchine in DMZ (non aprite la porta a chiunque, MAI).
Nel caso abbiate soluzioni che non gestiscano lo split dns e’ possibile intervenire con DNS configurati in maniera ibrida (cache, forwarder….) in maniera che la risoluzione interna ed esterna sia possibile per le macchine che lo richiedano.
DNS cache Sempre e dovunque
In realta’ l’uso del DNS cache sarebbe da consigliare sempre e comunque, persino per l’uso domestico. Provate ad installare sulle vostre macchine un DNS service (si trovano free o opensource per qualsiasi piattaforma) e vedete se ci sono differenze rispetto all’appoggiarvi al DNS del vostro provider.
ciao
Antonio

Surviving Tips:Performance e DNS was originally published on The Puchi Herald Magazine

Surviving Tips:Performance e DNS


Tra le cose piu spesso trascurate per quello che riguarda security e prestazioni, vi e’ sempre la struttura DNS.
I DNS sono un elemento fondamentale per garantire prestazioni sia per quello che concerne il trasferimento delle mail sia per quello che concerne la navigazione Web.
Anche utilizzando un SMTP Gateway o un Proxy non si puo’ prescidere dalle performance di un buon servizio di DNS. Paradossalmente poi in caso di uso di proxy un pessimo DNS puo’ dare origine ad una serie disparata di errori che, nei fatti, renderebbero la navigazione piu problematica e la use experience piu dura rispetto alla navigazione senza proxy.
Cerchiamo di capire a cosa serve e perche’ il servizio DNS e’ cosi importante, e come questo si integra nei servizi IronPort.
Come tutti sappiamo il servizio DNS (Domani Name System) serve per tradurre un nome nel relativo indirizzo IP.

Domain Name System (spesso indicato con DNS) è un servizio utilizzato per la risoluzione di nomi di host in indirizzi IP e viceversa. Il servizio è realizzato tramite un database distribuito, costituito dai server DNS.

Il nome DNS denota anche il protocollo che regola il funzionamento del servizio, i programmi che lo implementano, i server su cui questi girano, l’insieme di questi server che cooperano per fornire il servizio.

I nomi DNS, o “nomi di dominio”, sono una delle caratteristiche più visibili diInternet.

C’è confusione in merito alla definizione dell’acronimo: la S spesso viene interpretata come service, ma la definizione corretta è system.

L’operazione di convertire un nome in un indirizzo è detta risoluzione DNS, convertire un indirizzo IP in nome è detto risoluzione inversa.

la struttura dei domini e’ ad albero, si parte dalla root (.) per poi creare DNS autoritativi sulle classiche zone .com, .net, .tv, .tel etc etc etc.
Vi rimando a Wikipedia per approfondire la questione. e per riferimento potete usare i seguenti link:

 

Quando si crea un dominio si deve installare un DNS server che sia autoritativo per il proprio dominio, questa operazione viene fatta o in casa o dal providr che offre connettivita’.
Il DNS vienie quindi usato per offrire la risoluzione di nomi Host in IP, il problema e’ che tale risoluzione non e’ detto che sia veloce. tutti hanno sperimentato quanto possa durare la propagazione di un nome su internet (2448 ore) e tutti hanno sicuramente provato la lentezza derivante ad una cattiva risoluzione DNS, anche se spesso si attribuisce la lentezza di servizi e browsing a cause diverse.
Le soluzioni IronPort (ma non solo) usano pesantemente i servizi DNS in quanto questi sono essenziali per la corretta delivery dei servizi di Email e Web Browsing, inoltre il protocollo DNS viene utilizzato anche per interrogare Senderbase, lo scopo e’ quello di utilizzare un protocollo veloce, leggero, con una struttura ridondata.
Purtroppo la tendenza riguardo i DNS in italia e’ spesso quella di trascurarne l’importanza e la sicurezza, e questo si traduce nella cattiva abitudine di utilizzare il DNS come servizio secondario su macchine non sufficientemente performanti o, peggio, fare riferimento a DNS generici offerti piu o meno pubbicamente dai providers.
Questa cattiva abitudine porta spesso, come conseguenza, ad avere un calo sensibile di performance che viene, erroneamente, attribuita alle cause piu disparate.
Il problema
Sebbene sia necessario consentire la risoluzione pubblica ai domini su cui si ha autorita’ questo non significa necessariamente che dobbiamo porre in DMZ il nostro DNS principale.
Esistono diverse tecnologie che ci consentono di esporre solo la porzione di zona che siamo vincolati (o ci serve) esporre, tipicamente si espone su un DNS apposito in DMZ la porzione di zona interessata, che verra’ utilizzata su internet per poter permettere la risoluzione degli host esposti.
il problema nasce dal fatto che oltre ad esporre contenuti (la risoluzione degli host dei domini di cui si ha autorita’) il servizio DNS viene utilizzato anche da sorgenti interne ed in DMZ che richiedono o possono richiedere:
1) la risoluzione di host in domini pubblici non gestiti da voi
2) la risoluzione di host in domni privati che on e’ il caso di esporre pubblicamente (si pensi, ad esempio, alle esigenze di Active Directory).
Come gestire questa cosa?
Buona norma implementativa, sia che abbiate o meno un DNS autoritativo pubblico, e’ quella di mettere in DMZ un sistema ridondato di DNS Cache Only.
A questi DNS potrebbero puntare sia le macchine in DMZ che, eventualmente, le macchine interne che cercando di fare risoluzione.
Questo semplice accorgimento consente di effettuare una ottimizzazione sensibile in termini di latenze prestazionali legate ai DNS worldwide.
Innanzi tutto un chache only e’ molto facile da gestire, un minimo di hardening e’ ovviamente consigliabile, ma la cosa interessante e’ che, se si sfruttano anche meccanismi di virtualizzazione, la messa i opera in caso di problemi di tale oggetto e’ estremamente rapida.
L’uso di un cache only in DMZ vi consente, inoltre, di abbassare il rischio di DNS poisoning, infatti risulta ovvio che tale DNS e’ meno esposto sia di un autoritativo che di un DNS di un provider.
Un altro vantaggio di un DNS in casa di tipo cache only e’ anche legato al fatto che in cache potete mettere solo quello che effettivamente vi interessa, gestendo opportunamente TTL potete quindi ottimizzare pesantemente le risposte.
Sempre in termini di vantaggi vi e’ anche un evidente guadagno in termini di velocita’ di risposta alle query dovuto alla vicinanza del DNS cache server ai vostri client. Il vantaggio si sente, ovviamente, sia in termni di performance sulla DMZ che in termini di performance sulla LAN interna.
Il Dilemma di Active Directory e dei domini .local
Una delle osservazioni piu comuni cui vado incontro e’ legata alla considerazione che in ambiente AD esiste gia’ (ed e’ obbligatorio) un servizio DNS.
Active Directory, infatti, demanda alla risoluzione DNS la risoluzione dei nomi HOST e dei servizi, e quindi e’ un requisito fondamentale per la sua installazione. Ovviamente Microsoft offre un DNS integrato alla sua soluzione che serve a coprire egregiamente questa esigenza, offrendo anche, oltre alla integrazione in AD, il supporto dinamico di registrazione dei nomi e la capacita’ di rispondere a chiamate DNS standard.
Il risultato e’ che spesso ci si trova di fronte a realta’ in cui il dominio AD ha una estensione pubblica (.COM, .IT….)
Va da se che questa e’ una situazione poco gradevole in termni di security, in quanto nel caso, ad esempio, si forzi la sicurezza del DNS autoritativo si viene a conoscere l’intero indirizzamento delle macchine in AD. Non parliamo poi della sua diretta esposizione in DMZ (magari anche come global catalog….)
Una situazione piu prudente e’ quella di demandare al DNS interno di AD la gestione di un dominio non pubblico (.LOCAL, .BOH, .FATEVOI) e quindi non esporre semplicemente tale zona alla risoluzione su internet.
Nel caso le macchine interne debbano risolvere sia domini esterni che domini inetrni si pone allor ail problema di come configurare la cosa.
Dal punto di vista Ironpor il supporto dello split dns risolve il problema in maniera semplice ed efficace.
La idea di base e’ quella di puntare, per la risoluzione di un dominio pubblico generico, ad un DNS pubblico (o direttamente ai Root Server, in questo caso i Gateway Ironport si comportano come DNS chache only server, che pero’ accettano solo se stessi come client DNS), e per i domini privati a DNS opportunamente configurati per accettar query solo da un numero definito di macchine in DMZ (non aprite la porta a chiunque, MAI).
Nel caso abbiate soluzioni che non gestiscano lo split dns e’ possibile intervenire con DNS configurati in maniera ibrida (cache, forwarder….) in maniera che la risoluzione interna ed esterna sia possibile per le macchine che lo richiedano.
DNS cache Sempre e dovunque
In realta’ l’uso del DNS cache sarebbe da consigliare sempre e comunque, persino per l’uso domestico. Provate ad installare sulle vostre macchine un DNS service (si trovano free o opensource per qualsiasi piattaforma) e vedete se ci sono differenze rispetto all’appoggiarvi al DNS del vostro provider.
ciao
Antonio

Surviving Tips:Performance e DNS was originally published on The Puchi Herald Magazine

Surviving Tips:Performance e DNS


Tra le cose piu spesso trascurate per quello che riguarda security e prestazioni, vi e’ sempre la struttura DNS.
I DNS sono un elemento fondamentale per garantire prestazioni sia per quello che concerne il trasferimento delle mail sia per quello che concerne la navigazione Web.
Anche utilizzando un SMTP Gateway o un Proxy non si puo’ prescidere dalle performance di un buon servizio di DNS. Paradossalmente poi in caso di uso di proxy un pessimo DNS puo’ dare origine ad una serie disparata di errori che, nei fatti, renderebbero la navigazione piu problematica e la use experience piu dura rispetto alla navigazione senza proxy.
Cerchiamo di capire a cosa serve e perche’ il servizio DNS e’ cosi importante, e come questo si integra nei servizi IronPort.
Come tutti sappiamo il servizio DNS (Domani Name System) serve per tradurre un nome nel relativo indirizzo IP.

Domain Name System (spesso indicato con DNS) è un servizio utilizzato per la risoluzione di nomi di host in indirizzi IP e viceversa. Il servizio è realizzato tramite un database distribuito, costituito dai server DNS.

Il nome DNS denota anche il protocollo che regola il funzionamento del servizio, i programmi che lo implementano, i server su cui questi girano, l’insieme di questi server che cooperano per fornire il servizio.

I nomi DNS, o “nomi di dominio”, sono una delle caratteristiche più visibili diInternet.

C’è confusione in merito alla definizione dell’acronimo: la S spesso viene interpretata come service, ma la definizione corretta è system.

L’operazione di convertire un nome in un indirizzo è detta risoluzione DNS, convertire un indirizzo IP in nome è detto risoluzione inversa.

la struttura dei domini e’ ad albero, si parte dalla root (.) per poi creare DNS autoritativi sulle classiche zone .com, .net, .tv, .tel etc etc etc.
Vi rimando a Wikipedia per approfondire la questione. e per riferimento potete usare i seguenti link:

 

Quando si crea un dominio si deve installare un DNS server che sia autoritativo per il proprio dominio, questa operazione viene fatta o in casa o dal providr che offre connettivita’.
Il DNS vienie quindi usato per offrire la risoluzione di nomi Host in IP, il problema e’ che tale risoluzione non e’ detto che sia veloce. tutti hanno sperimentato quanto possa durare la propagazione di un nome su internet (2448 ore) e tutti hanno sicuramente provato la lentezza derivante ad una cattiva risoluzione DNS, anche se spesso si attribuisce la lentezza di servizi e browsing a cause diverse.
Le soluzioni IronPort (ma non solo) usano pesantemente i servizi DNS in quanto questi sono essenziali per la corretta delivery dei servizi di Email e Web Browsing, inoltre il protocollo DNS viene utilizzato anche per interrogare Senderbase, lo scopo e’ quello di utilizzare un protocollo veloce, leggero, con una struttura ridondata.
Purtroppo la tendenza riguardo i DNS in italia e’ spesso quella di trascurarne l’importanza e la sicurezza, e questo si traduce nella cattiva abitudine di utilizzare il DNS come servizio secondario su macchine non sufficientemente performanti o, peggio, fare riferimento a DNS generici offerti piu o meno pubbicamente dai providers.
Questa cattiva abitudine porta spesso, come conseguenza, ad avere un calo sensibile di performance che viene, erroneamente, attribuita alle cause piu disparate.
Il problema
Sebbene sia necessario consentire la risoluzione pubblica ai domini su cui si ha autorita’ questo non significa necessariamente che dobbiamo porre in DMZ il nostro DNS principale.
Esistono diverse tecnologie che ci consentono di esporre solo la porzione di zona che siamo vincolati (o ci serve) esporre, tipicamente si espone su un DNS apposito in DMZ la porzione di zona interessata, che verra’ utilizzata su internet per poter permettere la risoluzione degli host esposti.
il problema nasce dal fatto che oltre ad esporre contenuti (la risoluzione degli host dei domini di cui si ha autorita’) il servizio DNS viene utilizzato anche da sorgenti interne ed in DMZ che richiedono o possono richiedere:
1) la risoluzione di host in domini pubblici non gestiti da voi
2) la risoluzione di host in domni privati che on e’ il caso di esporre pubblicamente (si pensi, ad esempio, alle esigenze di Active Directory).
Come gestire questa cosa?
Buona norma implementativa, sia che abbiate o meno un DNS autoritativo pubblico, e’ quella di mettere in DMZ un sistema ridondato di DNS Cache Only.
A questi DNS potrebbero puntare sia le macchine in DMZ che, eventualmente, le macchine interne che cercando di fare risoluzione.
Questo semplice accorgimento consente di effettuare una ottimizzazione sensibile in termini di latenze prestazionali legate ai DNS worldwide.
Innanzi tutto un chache only e’ molto facile da gestire, un minimo di hardening e’ ovviamente consigliabile, ma la cosa interessante e’ che, se si sfruttano anche meccanismi di virtualizzazione, la messa i opera in caso di problemi di tale oggetto e’ estremamente rapida.
L’uso di un cache only in DMZ vi consente, inoltre, di abbassare il rischio di DNS poisoning, infatti risulta ovvio che tale DNS e’ meno esposto sia di un autoritativo che di un DNS di un provider.
Un altro vantaggio di un DNS in casa di tipo cache only e’ anche legato al fatto che in cache potete mettere solo quello che effettivamente vi interessa, gestendo opportunamente TTL potete quindi ottimizzare pesantemente le risposte.
Sempre in termini di vantaggi vi e’ anche un evidente guadagno in termini di velocita’ di risposta alle query dovuto alla vicinanza del DNS cache server ai vostri client. Il vantaggio si sente, ovviamente, sia in termni di performance sulla DMZ che in termini di performance sulla LAN interna.
Il Dilemma di Active Directory e dei domini .local
Una delle osservazioni piu comuni cui vado incontro e’ legata alla considerazione che in ambiente AD esiste gia’ (ed e’ obbligatorio) un servizio DNS.
Active Directory, infatti, demanda alla risoluzione DNS la risoluzione dei nomi HOST e dei servizi, e quindi e’ un requisito fondamentale per la sua installazione. Ovviamente Microsoft offre un DNS integrato alla sua soluzione che serve a coprire egregiamente questa esigenza, offrendo anche, oltre alla integrazione in AD, il supporto dinamico di registrazione dei nomi e la capacita’ di rispondere a chiamate DNS standard.
Il risultato e’ che spesso ci si trova di fronte a realta’ in cui il dominio AD ha una estensione pubblica (.COM, .IT….)
Va da se che questa e’ una situazione poco gradevole in termni di security, in quanto nel caso, ad esempio, si forzi la sicurezza del DNS autoritativo si viene a conoscere l’intero indirizzamento delle macchine in AD. Non parliamo poi della sua diretta esposizione in DMZ (magari anche come global catalog….)
Una situazione piu prudente e’ quella di demandare al DNS interno di AD la gestione di un dominio non pubblico (.LOCAL, .BOH, .FATEVOI) e quindi non esporre semplicemente tale zona alla risoluzione su internet.
Nel caso le macchine interne debbano risolvere sia domini esterni che domini inetrni si pone allor ail problema di come configurare la cosa.
Dal punto di vista Ironpor il supporto dello split dns risolve il problema in maniera semplice ed efficace.
La idea di base e’ quella di puntare, per la risoluzione di un dominio pubblico generico, ad un DNS pubblico (o direttamente ai Root Server, in questo caso i Gateway Ironport si comportano come DNS chache only server, che pero’ accettano solo se stessi come client DNS), e per i domini privati a DNS opportunamente configurati per accettar query solo da un numero definito di macchine in DMZ (non aprite la porta a chiunque, MAI).
Nel caso abbiate soluzioni che non gestiscano lo split dns e’ possibile intervenire con DNS configurati in maniera ibrida (cache, forwarder….) in maniera che la risoluzione interna ed esterna sia possibile per le macchine che lo richiedano.
DNS cache Sempre e dovunque
In realta’ l’uso del DNS cache sarebbe da consigliare sempre e comunque, persino per l’uso domestico. Provate ad installare sulle vostre macchine un DNS service (si trovano free o opensource per qualsiasi piattaforma) e vedete se ci sono differenze rispetto all’appoggiarvi al DNS del vostro provider.
ciao
Antonio

Surviving Tips:Performance e DNS was originally published on The Puchi Herald Magazine

Surviving Tips:Performance e DNS


Tra le cose piu spesso trascurate per quello che riguarda security e prestazioni, vi e’ sempre la struttura DNS.
I DNS sono un elemento fondamentale per garantire prestazioni sia per quello che concerne il trasferimento delle mail sia per quello che concerne la navigazione Web.
Anche utilizzando un SMTP Gateway o un Proxy non si puo’ prescidere dalle performance di un buon servizio di DNS. Paradossalmente poi in caso di uso di proxy un pessimo DNS puo’ dare origine ad una serie disparata di errori che, nei fatti, renderebbero la navigazione piu problematica e la use experience piu dura rispetto alla navigazione senza proxy.
Cerchiamo di capire a cosa serve e perche’ il servizio DNS e’ cosi importante, e come questo si integra nei servizi IronPort.
Come tutti sappiamo il servizio DNS (Domani Name System) serve per tradurre un nome nel relativo indirizzo IP.

Domain Name System (spesso indicato con DNS) è un servizio utilizzato per la risoluzione di nomi di host in indirizzi IP e viceversa. Il servizio è realizzato tramite un database distribuito, costituito dai server DNS.

Il nome DNS denota anche il protocollo che regola il funzionamento del servizio, i programmi che lo implementano, i server su cui questi girano, l’insieme di questi server che cooperano per fornire il servizio.

I nomi DNS, o “nomi di dominio”, sono una delle caratteristiche più visibili diInternet.

C’è confusione in merito alla definizione dell’acronimo: la S spesso viene interpretata come service, ma la definizione corretta è system.

L’operazione di convertire un nome in un indirizzo è detta risoluzione DNS, convertire un indirizzo IP in nome è detto risoluzione inversa.

la struttura dei domini e’ ad albero, si parte dalla root (.) per poi creare DNS autoritativi sulle classiche zone .com, .net, .tv, .tel etc etc etc.
Vi rimando a Wikipedia per approfondire la questione. e per riferimento potete usare i seguenti link:

 

Quando si crea un dominio si deve installare un DNS server che sia autoritativo per il proprio dominio, questa operazione viene fatta o in casa o dal providr che offre connettivita’.
Il DNS vienie quindi usato per offrire la risoluzione di nomi Host in IP, il problema e’ che tale risoluzione non e’ detto che sia veloce. tutti hanno sperimentato quanto possa durare la propagazione di un nome su internet (2448 ore) e tutti hanno sicuramente provato la lentezza derivante ad una cattiva risoluzione DNS, anche se spesso si attribuisce la lentezza di servizi e browsing a cause diverse.
Le soluzioni IronPort (ma non solo) usano pesantemente i servizi DNS in quanto questi sono essenziali per la corretta delivery dei servizi di Email e Web Browsing, inoltre il protocollo DNS viene utilizzato anche per interrogare Senderbase, lo scopo e’ quello di utilizzare un protocollo veloce, leggero, con una struttura ridondata.
Purtroppo la tendenza riguardo i DNS in italia e’ spesso quella di trascurarne l’importanza e la sicurezza, e questo si traduce nella cattiva abitudine di utilizzare il DNS come servizio secondario su macchine non sufficientemente performanti o, peggio, fare riferimento a DNS generici offerti piu o meno pubbicamente dai providers.
Questa cattiva abitudine porta spesso, come conseguenza, ad avere un calo sensibile di performance che viene, erroneamente, attribuita alle cause piu disparate.
Il problema
Sebbene sia necessario consentire la risoluzione pubblica ai domini su cui si ha autorita’ questo non significa necessariamente che dobbiamo porre in DMZ il nostro DNS principale.
Esistono diverse tecnologie che ci consentono di esporre solo la porzione di zona che siamo vincolati (o ci serve) esporre, tipicamente si espone su un DNS apposito in DMZ la porzione di zona interessata, che verra’ utilizzata su internet per poter permettere la risoluzione degli host esposti.
il problema nasce dal fatto che oltre ad esporre contenuti (la risoluzione degli host dei domini di cui si ha autorita’) il servizio DNS viene utilizzato anche da sorgenti interne ed in DMZ che richiedono o possono richiedere:
1) la risoluzione di host in domini pubblici non gestiti da voi
2) la risoluzione di host in domni privati che on e’ il caso di esporre pubblicamente (si pensi, ad esempio, alle esigenze di Active Directory).
Come gestire questa cosa?
Buona norma implementativa, sia che abbiate o meno un DNS autoritativo pubblico, e’ quella di mettere in DMZ un sistema ridondato di DNS Cache Only.
A questi DNS potrebbero puntare sia le macchine in DMZ che, eventualmente, le macchine interne che cercando di fare risoluzione.
Questo semplice accorgimento consente di effettuare una ottimizzazione sensibile in termini di latenze prestazionali legate ai DNS worldwide.
Innanzi tutto un chache only e’ molto facile da gestire, un minimo di hardening e’ ovviamente consigliabile, ma la cosa interessante e’ che, se si sfruttano anche meccanismi di virtualizzazione, la messa i opera in caso di problemi di tale oggetto e’ estremamente rapida.
L’uso di un cache only in DMZ vi consente, inoltre, di abbassare il rischio di DNS poisoning, infatti risulta ovvio che tale DNS e’ meno esposto sia di un autoritativo che di un DNS di un provider.
Un altro vantaggio di un DNS in casa di tipo cache only e’ anche legato al fatto che in cache potete mettere solo quello che effettivamente vi interessa, gestendo opportunamente TTL potete quindi ottimizzare pesantemente le risposte.
Sempre in termini di vantaggi vi e’ anche un evidente guadagno in termini di velocita’ di risposta alle query dovuto alla vicinanza del DNS cache server ai vostri client. Il vantaggio si sente, ovviamente, sia in termni di performance sulla DMZ che in termini di performance sulla LAN interna.
Il Dilemma di Active Directory e dei domini .local
Una delle osservazioni piu comuni cui vado incontro e’ legata alla considerazione che in ambiente AD esiste gia’ (ed e’ obbligatorio) un servizio DNS.
Active Directory, infatti, demanda alla risoluzione DNS la risoluzione dei nomi HOST e dei servizi, e quindi e’ un requisito fondamentale per la sua installazione. Ovviamente Microsoft offre un DNS integrato alla sua soluzione che serve a coprire egregiamente questa esigenza, offrendo anche, oltre alla integrazione in AD, il supporto dinamico di registrazione dei nomi e la capacita’ di rispondere a chiamate DNS standard.
Il risultato e’ che spesso ci si trova di fronte a realta’ in cui il dominio AD ha una estensione pubblica (.COM, .IT….)
Va da se che questa e’ una situazione poco gradevole in termni di security, in quanto nel caso, ad esempio, si forzi la sicurezza del DNS autoritativo si viene a conoscere l’intero indirizzamento delle macchine in AD. Non parliamo poi della sua diretta esposizione in DMZ (magari anche come global catalog….)
Una situazione piu prudente e’ quella di demandare al DNS interno di AD la gestione di un dominio non pubblico (.LOCAL, .BOH, .FATEVOI) e quindi non esporre semplicemente tale zona alla risoluzione su internet.
Nel caso le macchine interne debbano risolvere sia domini esterni che domini inetrni si pone allor ail problema di come configurare la cosa.
Dal punto di vista Ironpor il supporto dello split dns risolve il problema in maniera semplice ed efficace.
La idea di base e’ quella di puntare, per la risoluzione di un dominio pubblico generico, ad un DNS pubblico (o direttamente ai Root Server, in questo caso i Gateway Ironport si comportano come DNS chache only server, che pero’ accettano solo se stessi come client DNS), e per i domini privati a DNS opportunamente configurati per accettar query solo da un numero definito di macchine in DMZ (non aprite la porta a chiunque, MAI).
Nel caso abbiate soluzioni che non gestiscano lo split dns e’ possibile intervenire con DNS configurati in maniera ibrida (cache, forwarder….) in maniera che la risoluzione interna ed esterna sia possibile per le macchine che lo richiedano.
DNS cache Sempre e dovunque
In realta’ l’uso del DNS cache sarebbe da consigliare sempre e comunque, persino per l’uso domestico. Provate ad installare sulle vostre macchine un DNS service (si trovano free o opensource per qualsiasi piattaforma) e vedete se ci sono differenze rispetto all’appoggiarvi al DNS del vostro provider.
ciao
Antonio

Surviving Tips:Performance e DNS was originally published on The Puchi Herald Magazine

Surviving Tips:Performance e DNS


Tra le cose piu spesso trascurate per quello che riguarda security e prestazioni, vi e’ sempre la struttura DNS.
I DNS sono un elemento fondamentale per garantire prestazioni sia per quello che concerne il trasferimento delle mail sia per quello che concerne la navigazione Web.
Anche utilizzando un SMTP Gateway o un Proxy non si puo’ prescidere dalle performance di un buon servizio di DNS. Paradossalmente poi in caso di uso di proxy un pessimo DNS puo’ dare origine ad una serie disparata di errori che, nei fatti, renderebbero la navigazione piu problematica e la use experience piu dura rispetto alla navigazione senza proxy.
Cerchiamo di capire a cosa serve e perche’ il servizio DNS e’ cosi importante, e come questo si integra nei servizi IronPort.
Come tutti sappiamo il servizio DNS (Domani Name System) serve per tradurre un nome nel relativo indirizzo IP.

Domain Name System (spesso indicato con DNS) è un servizio utilizzato per la risoluzione di nomi di host in indirizzi IP e viceversa. Il servizio è realizzato tramite un database distribuito, costituito dai server DNS.

Il nome DNS denota anche il protocollo che regola il funzionamento del servizio, i programmi che lo implementano, i server su cui questi girano, l’insieme di questi server che cooperano per fornire il servizio.

I nomi DNS, o “nomi di dominio”, sono una delle caratteristiche più visibili diInternet.

C’è confusione in merito alla definizione dell’acronimo: la S spesso viene interpretata come service, ma la definizione corretta è system.

L’operazione di convertire un nome in un indirizzo è detta risoluzione DNS, convertire un indirizzo IP in nome è detto risoluzione inversa.

la struttura dei domini e’ ad albero, si parte dalla root (.) per poi creare DNS autoritativi sulle classiche zone .com, .net, .tv, .tel etc etc etc.
Vi rimando a Wikipedia per approfondire la questione. e per riferimento potete usare i seguenti link:

 

Quando si crea un dominio si deve installare un DNS server che sia autoritativo per il proprio dominio, questa operazione viene fatta o in casa o dal providr che offre connettivita’.
Il DNS vienie quindi usato per offrire la risoluzione di nomi Host in IP, il problema e’ che tale risoluzione non e’ detto che sia veloce. tutti hanno sperimentato quanto possa durare la propagazione di un nome su internet (2448 ore) e tutti hanno sicuramente provato la lentezza derivante ad una cattiva risoluzione DNS, anche se spesso si attribuisce la lentezza di servizi e browsing a cause diverse.
Le soluzioni IronPort (ma non solo) usano pesantemente i servizi DNS in quanto questi sono essenziali per la corretta delivery dei servizi di Email e Web Browsing, inoltre il protocollo DNS viene utilizzato anche per interrogare Senderbase, lo scopo e’ quello di utilizzare un protocollo veloce, leggero, con una struttura ridondata.
Purtroppo la tendenza riguardo i DNS in italia e’ spesso quella di trascurarne l’importanza e la sicurezza, e questo si traduce nella cattiva abitudine di utilizzare il DNS come servizio secondario su macchine non sufficientemente performanti o, peggio, fare riferimento a DNS generici offerti piu o meno pubbicamente dai providers.
Questa cattiva abitudine porta spesso, come conseguenza, ad avere un calo sensibile di performance che viene, erroneamente, attribuita alle cause piu disparate.
Il problema
Sebbene sia necessario consentire la risoluzione pubblica ai domini su cui si ha autorita’ questo non significa necessariamente che dobbiamo porre in DMZ il nostro DNS principale.
Esistono diverse tecnologie che ci consentono di esporre solo la porzione di zona che siamo vincolati (o ci serve) esporre, tipicamente si espone su un DNS apposito in DMZ la porzione di zona interessata, che verra’ utilizzata su internet per poter permettere la risoluzione degli host esposti.
il problema nasce dal fatto che oltre ad esporre contenuti (la risoluzione degli host dei domini di cui si ha autorita’) il servizio DNS viene utilizzato anche da sorgenti interne ed in DMZ che richiedono o possono richiedere:
1) la risoluzione di host in domini pubblici non gestiti da voi
2) la risoluzione di host in domni privati che on e’ il caso di esporre pubblicamente (si pensi, ad esempio, alle esigenze di Active Directory).
Come gestire questa cosa?
Buona norma implementativa, sia che abbiate o meno un DNS autoritativo pubblico, e’ quella di mettere in DMZ un sistema ridondato di DNS Cache Only.
A questi DNS potrebbero puntare sia le macchine in DMZ che, eventualmente, le macchine interne che cercando di fare risoluzione.
Questo semplice accorgimento consente di effettuare una ottimizzazione sensibile in termini di latenze prestazionali legate ai DNS worldwide.
Innanzi tutto un chache only e’ molto facile da gestire, un minimo di hardening e’ ovviamente consigliabile, ma la cosa interessante e’ che, se si sfruttano anche meccanismi di virtualizzazione, la messa i opera in caso di problemi di tale oggetto e’ estremamente rapida.
L’uso di un cache only in DMZ vi consente, inoltre, di abbassare il rischio di DNS poisoning, infatti risulta ovvio che tale DNS e’ meno esposto sia di un autoritativo che di un DNS di un provider.
Un altro vantaggio di un DNS in casa di tipo cache only e’ anche legato al fatto che in cache potete mettere solo quello che effettivamente vi interessa, gestendo opportunamente TTL potete quindi ottimizzare pesantemente le risposte.
Sempre in termini di vantaggi vi e’ anche un evidente guadagno in termini di velocita’ di risposta alle query dovuto alla vicinanza del DNS cache server ai vostri client. Il vantaggio si sente, ovviamente, sia in termni di performance sulla DMZ che in termini di performance sulla LAN interna.
Il Dilemma di Active Directory e dei domini .local
Una delle osservazioni piu comuni cui vado incontro e’ legata alla considerazione che in ambiente AD esiste gia’ (ed e’ obbligatorio) un servizio DNS.
Active Directory, infatti, demanda alla risoluzione DNS la risoluzione dei nomi HOST e dei servizi, e quindi e’ un requisito fondamentale per la sua installazione. Ovviamente Microsoft offre un DNS integrato alla sua soluzione che serve a coprire egregiamente questa esigenza, offrendo anche, oltre alla integrazione in AD, il supporto dinamico di registrazione dei nomi e la capacita’ di rispondere a chiamate DNS standard.
Il risultato e’ che spesso ci si trova di fronte a realta’ in cui il dominio AD ha una estensione pubblica (.COM, .IT….)
Va da se che questa e’ una situazione poco gradevole in termni di security, in quanto nel caso, ad esempio, si forzi la sicurezza del DNS autoritativo si viene a conoscere l’intero indirizzamento delle macchine in AD. Non parliamo poi della sua diretta esposizione in DMZ (magari anche come global catalog….)
Una situazione piu prudente e’ quella di demandare al DNS interno di AD la gestione di un dominio non pubblico (.LOCAL, .BOH, .FATEVOI) e quindi non esporre semplicemente tale zona alla risoluzione su internet.
Nel caso le macchine interne debbano risolvere sia domini esterni che domini inetrni si pone allor ail problema di come configurare la cosa.
Dal punto di vista Ironpor il supporto dello split dns risolve il problema in maniera semplice ed efficace.
La idea di base e’ quella di puntare, per la risoluzione di un dominio pubblico generico, ad un DNS pubblico (o direttamente ai Root Server, in questo caso i Gateway Ironport si comportano come DNS chache only server, che pero’ accettano solo se stessi come client DNS), e per i domini privati a DNS opportunamente configurati per accettar query solo da un numero definito di macchine in DMZ (non aprite la porta a chiunque, MAI).
Nel caso abbiate soluzioni che non gestiscano lo split dns e’ possibile intervenire con DNS configurati in maniera ibrida (cache, forwarder….) in maniera che la risoluzione interna ed esterna sia possibile per le macchine che lo richiedano.
DNS cache Sempre e dovunque
In realta’ l’uso del DNS cache sarebbe da consigliare sempre e comunque, persino per l’uso domestico. Provate ad installare sulle vostre macchine un DNS service (si trovano free o opensource per qualsiasi piattaforma) e vedete se ci sono differenze rispetto all’appoggiarvi al DNS del vostro provider.
ciao
Antonio

Surviving Tips:Performance e DNS was originally published on The Puchi Herald Magazine

Surviving Tips:Performance e DNS


Tra le cose piu spesso trascurate per quello che riguarda security e prestazioni, vi e’ sempre la struttura DNS.
I DNS sono un elemento fondamentale per garantire prestazioni sia per quello che concerne il trasferimento delle mail sia per quello che concerne la navigazione Web.
Anche utilizzando un SMTP Gateway o un Proxy non si puo’ prescidere dalle performance di un buon servizio di DNS. Paradossalmente poi in caso di uso di proxy un pessimo DNS puo’ dare origine ad una serie disparata di errori che, nei fatti, renderebbero la navigazione piu problematica e la use experience piu dura rispetto alla navigazione senza proxy.
Cerchiamo di capire a cosa serve e perche’ il servizio DNS e’ cosi importante, e come questo si integra nei servizi IronPort.
Come tutti sappiamo il servizio DNS (Domani Name System) serve per tradurre un nome nel relativo indirizzo IP.

Domain Name System (spesso indicato con DNS) è un servizio utilizzato per la risoluzione di nomi di host in indirizzi IP e viceversa. Il servizio è realizzato tramite un database distribuito, costituito dai server DNS.

Il nome DNS denota anche il protocollo che regola il funzionamento del servizio, i programmi che lo implementano, i server su cui questi girano, l’insieme di questi server che cooperano per fornire il servizio.

I nomi DNS, o “nomi di dominio”, sono una delle caratteristiche più visibili diInternet.

C’è confusione in merito alla definizione dell’acronimo: la S spesso viene interpretata come service, ma la definizione corretta è system.

L’operazione di convertire un nome in un indirizzo è detta risoluzione DNS, convertire un indirizzo IP in nome è detto risoluzione inversa.

la struttura dei domini e’ ad albero, si parte dalla root (.) per poi creare DNS autoritativi sulle classiche zone .com, .net, .tv, .tel etc etc etc.
Vi rimando a Wikipedia per approfondire la questione. e per riferimento potete usare i seguenti link:

 

Quando si crea un dominio si deve installare un DNS server che sia autoritativo per il proprio dominio, questa operazione viene fatta o in casa o dal providr che offre connettivita’.
Il DNS vienie quindi usato per offrire la risoluzione di nomi Host in IP, il problema e’ che tale risoluzione non e’ detto che sia veloce. tutti hanno sperimentato quanto possa durare la propagazione di un nome su internet (2448 ore) e tutti hanno sicuramente provato la lentezza derivante ad una cattiva risoluzione DNS, anche se spesso si attribuisce la lentezza di servizi e browsing a cause diverse.
Le soluzioni IronPort (ma non solo) usano pesantemente i servizi DNS in quanto questi sono essenziali per la corretta delivery dei servizi di Email e Web Browsing, inoltre il protocollo DNS viene utilizzato anche per interrogare Senderbase, lo scopo e’ quello di utilizzare un protocollo veloce, leggero, con una struttura ridondata.
Purtroppo la tendenza riguardo i DNS in italia e’ spesso quella di trascurarne l’importanza e la sicurezza, e questo si traduce nella cattiva abitudine di utilizzare il DNS come servizio secondario su macchine non sufficientemente performanti o, peggio, fare riferimento a DNS generici offerti piu o meno pubbicamente dai providers.
Questa cattiva abitudine porta spesso, come conseguenza, ad avere un calo sensibile di performance che viene, erroneamente, attribuita alle cause piu disparate.
Il problema
Sebbene sia necessario consentire la risoluzione pubblica ai domini su cui si ha autorita’ questo non significa necessariamente che dobbiamo porre in DMZ il nostro DNS principale.
Esistono diverse tecnologie che ci consentono di esporre solo la porzione di zona che siamo vincolati (o ci serve) esporre, tipicamente si espone su un DNS apposito in DMZ la porzione di zona interessata, che verra’ utilizzata su internet per poter permettere la risoluzione degli host esposti.
il problema nasce dal fatto che oltre ad esporre contenuti (la risoluzione degli host dei domini di cui si ha autorita’) il servizio DNS viene utilizzato anche da sorgenti interne ed in DMZ che richiedono o possono richiedere:
1) la risoluzione di host in domini pubblici non gestiti da voi
2) la risoluzione di host in domni privati che on e’ il caso di esporre pubblicamente (si pensi, ad esempio, alle esigenze di Active Directory).
Come gestire questa cosa?
Buona norma implementativa, sia che abbiate o meno un DNS autoritativo pubblico, e’ quella di mettere in DMZ un sistema ridondato di DNS Cache Only.
A questi DNS potrebbero puntare sia le macchine in DMZ che, eventualmente, le macchine interne che cercando di fare risoluzione.
Questo semplice accorgimento consente di effettuare una ottimizzazione sensibile in termini di latenze prestazionali legate ai DNS worldwide.
Innanzi tutto un chache only e’ molto facile da gestire, un minimo di hardening e’ ovviamente consigliabile, ma la cosa interessante e’ che, se si sfruttano anche meccanismi di virtualizzazione, la messa i opera in caso di problemi di tale oggetto e’ estremamente rapida.
L’uso di un cache only in DMZ vi consente, inoltre, di abbassare il rischio di DNS poisoning, infatti risulta ovvio che tale DNS e’ meno esposto sia di un autoritativo che di un DNS di un provider.
Un altro vantaggio di un DNS in casa di tipo cache only e’ anche legato al fatto che in cache potete mettere solo quello che effettivamente vi interessa, gestendo opportunamente TTL potete quindi ottimizzare pesantemente le risposte.
Sempre in termini di vantaggi vi e’ anche un evidente guadagno in termini di velocita’ di risposta alle query dovuto alla vicinanza del DNS cache server ai vostri client. Il vantaggio si sente, ovviamente, sia in termni di performance sulla DMZ che in termini di performance sulla LAN interna.
Il Dilemma di Active Directory e dei domini .local
Una delle osservazioni piu comuni cui vado incontro e’ legata alla considerazione che in ambiente AD esiste gia’ (ed e’ obbligatorio) un servizio DNS.
Active Directory, infatti, demanda alla risoluzione DNS la risoluzione dei nomi HOST e dei servizi, e quindi e’ un requisito fondamentale per la sua installazione. Ovviamente Microsoft offre un DNS integrato alla sua soluzione che serve a coprire egregiamente questa esigenza, offrendo anche, oltre alla integrazione in AD, il supporto dinamico di registrazione dei nomi e la capacita’ di rispondere a chiamate DNS standard.
Il risultato e’ che spesso ci si trova di fronte a realta’ in cui il dominio AD ha una estensione pubblica (.COM, .IT….)
Va da se che questa e’ una situazione poco gradevole in termni di security, in quanto nel caso, ad esempio, si forzi la sicurezza del DNS autoritativo si viene a conoscere l’intero indirizzamento delle macchine in AD. Non parliamo poi della sua diretta esposizione in DMZ (magari anche come global catalog….)
Una situazione piu prudente e’ quella di demandare al DNS interno di AD la gestione di un dominio non pubblico (.LOCAL, .BOH, .FATEVOI) e quindi non esporre semplicemente tale zona alla risoluzione su internet.
Nel caso le macchine interne debbano risolvere sia domini esterni che domini inetrni si pone allor ail problema di come configurare la cosa.
Dal punto di vista Ironpor il supporto dello split dns risolve il problema in maniera semplice ed efficace.
La idea di base e’ quella di puntare, per la risoluzione di un dominio pubblico generico, ad un DNS pubblico (o direttamente ai Root Server, in questo caso i Gateway Ironport si comportano come DNS chache only server, che pero’ accettano solo se stessi come client DNS), e per i domini privati a DNS opportunamente configurati per accettar query solo da un numero definito di macchine in DMZ (non aprite la porta a chiunque, MAI).
Nel caso abbiate soluzioni che non gestiscano lo split dns e’ possibile intervenire con DNS configurati in maniera ibrida (cache, forwarder….) in maniera che la risoluzione interna ed esterna sia possibile per le macchine che lo richiedano.
DNS cache Sempre e dovunque
In realta’ l’uso del DNS cache sarebbe da consigliare sempre e comunque, persino per l’uso domestico. Provate ad installare sulle vostre macchine un DNS service (si trovano free o opensource per qualsiasi piattaforma) e vedete se ci sono differenze rispetto all’appoggiarvi al DNS del vostro provider.
ciao
Antonio

Surviving Tips:Performance e DNS was originally published on The Puchi Herald Magazine