Passa al contenuto principale

5. Autorizzazione

I trasferimenti di zona possono esporre informazioni sensibili sulla struttura e il contenuto di una zona, aiutando potenzialmente gli aggressori nelle attività di ricognizione. Per questo motivo, i server AXFR tipicamente impiegano meccanismi di autorizzazione per restringere i trasferimenti di zona ai soli client fidati.

Questa sezione descrive le tecniche di autorizzazione comuni utilizzate nelle implementazioni AXFR. Si noti che questo documento non impone alcun metodo di autorizzazione specifico; gli implementatori e gli operatori sono liberi di scegliere l'approccio che meglio si adatta ai loro requisiti di sicurezza.

Tecniche di autorizzazione comuni

  1. Liste di controllo accessi (ACL): Un server AXFR PUÒ utilizzare ACL basate su indirizzi IP per restringere quali client sono autorizzati a richiedere trasferimenti di zona. Il server verifica l'indirizzo IP di origine della connessione TCP in arrivo contro un elenco configurato di indirizzi o reti consentiti.

    • Vantaggi: Semplice da implementare e configurare.
    • Limitazioni: Vulnerabile allo spoofing dell'indirizzo IP (sebbene l'handshake a tre vie di TCP fornisca una certa protezione). Non adatto a client con indirizzi IP dinamici.
  2. TSIG (Transaction Signature): TSIG [RFC2845] fornisce autenticazione crittografica dei messaggi DNS utilizzando chiavi segrete condivise. Un server AXFR PUÒ richiedere l'autenticazione TSIG per le richieste di trasferimento di zona.

    • Vantaggi: Fornisce autenticazione forte e integrità dei messaggi. Non dipende dagli indirizzi IP.
    • Limitazioni: Richiede che le chiavi pre-condivise siano configurate sia sul client che sul server. La gestione delle chiavi può essere impegnativa in grandi distribuzioni.
  3. SIG(0) (Signature): SIG(0) [RFC2931] fornisce autenticazione basata su chiave pubblica dei messaggi DNS. Un server AXFR PUÒ utilizzare SIG(0) per autenticare le query AXFR.

    • Vantaggi: Utilizza la crittografia a chiave pubblica, evitando la necessità di segreti pre-condivisi. Adatto a scenari in cui la gestione delle chiavi TSIG è impraticabile.
    • Limitazioni: Più complesso da implementare e configurare rispetto a TSIG. Richiede un'infrastruttura a chiave pubblica.
  4. TLS/SSL: Sebbene non specificato in questo documento, un server AXFR PUÒ utilizzare TLS o SSL per crittografare e autenticare le connessioni TCP utilizzate per i trasferimenti di zona. Questo approccio non è standardizzato per i trasferimenti di zona DNS ma può essere utilizzato in ambienti privati o controllati.

  5. VPN o reti private: In alcune distribuzioni, i trasferimenti di zona sono condotti su reti private (ad esempio, VPN [RFC2764]) che non sono accessibili all'Internet pubblico. Questo approccio si basa sulla sicurezza a livello di rete piuttosto che sull'autenticazione a livello di applicazione.

Politica di autorizzazione

Un server AXFR DOVREBBE implementare una politica di autorizzazione configurabile che determina quali client sono autorizzati a richiedere trasferimenti di zona. La politica DOVREBBE supportare almeno una delle tecniche di autorizzazione elencate sopra.

Un server AXFR DEVE rispondere alle query AXFR non autorizzate con un messaggio di risposta DNS contenente RCODE REFUSED (5). Questo informa il client che il trasferimento di zona è stato negato a causa di restrizioni di politica.

Comportamento predefinito

Il comportamento predefinito di un server AXFR riguardo all'autorizzazione non è specificato da questo documento. Gli implementatori DOVREBBERO scegliere un comportamento predefinito sicuro, come:

  • Negare tutte le richieste di trasferimento di zona per impostazione predefinita, richiedendo configurazione esplicita per consentire client specifici, o
  • Consentire trasferimenti di zona solo da indirizzi IP specifici configurati come server secondari.

Un server AXFR NON DEVE consentire trasferimenti di zona illimitati a client arbitrari per impostazione predefinita, poiché ciò rappresenta un rischio di sicurezza significativo.

Metodi di autorizzazione multipli

Un server AXFR PUÒ supportare più metodi di autorizzazione simultaneamente. Ad esempio, un server potrebbe richiedere sia la corrispondenza ACL basata su indirizzo IP che l'autenticazione TSIG affinché un trasferimento di zona sia consentito. I dettagli della combinazione di più metodi di autorizzazione dipendono dall'implementazione.

Fallimenti di autorizzazione

Se una query AXFR non supera i controlli di autorizzazione, il server AXFR DOVREBBE rispondere con RCODE REFUSED. Il server PUÒ registrare il tentativo di autorizzazione fallito a scopi di audit.

Un server AXFR NON DEVE rivelare dettagli sul motivo per cui l'autorizzazione è fallita (ad esempio, restituendo codici di errore diversi per ragioni di fallimento diverse), poiché ciò potrebbe fornire informazioni utili a potenziali aggressori.