Implementazioni NTP a pieno titolo consentono solo un limite di inclinazione. Ad esempio, l'implementazione di fatto standard (precedentemente ISC) su Linux non si discosterà dall'orologio locale di oltre 1/2000 per impostazione predefinita (un po 'meno di un minuto al giorno). Quindi un attaccante non può causare un'enorme deviazione dell'orologio con una tale implementazione. In una tipica impostazione a livello di sito o server, un utente malintenzionato che può causare la deriva del tuo orologio può anche fare cose molto più preoccupanti, tra cui un DoS significativo.
Se hai bisogno di maggiore precisione, prendi un orologio che non si basa su Internet. Puoi ricevere segnali orari da molti trasmettitori radio , da GPS , ecc. I ricevitori iniziano circa $ 10 circa. Un orologio atomico ti rende più indipendente, ma è, ahem, decisamente più costoso.
Le implementazioni NTP su dispositivi embedded (incluse molte appliance di rete) sono spesso più stupide. Molti di essi resetteranno la data una volta al giorno senza eseguire alcun controllo di coerenza (specialmente quelli senza un orologio interno, che comunque deve ottenere una data all'avvio). Quindi, se possibile, assicurati di configurare tutti questi dispositivi per ottenere il tempo da un server affidabile nella rete interna , non su Internet.
Se hai bisogno di maggiore sicurezza, NTP supporta controlli di integrità e autenticità in tempo segnali. Questi sono sufficienti per proteggere contro un utente malintenzionato che inietta solo pacchetti di risposta NTP falsi. Se l'attaccante può ritardare i pacchetti legittimi in transito, l'autenticazione dei pacchetti non è sufficiente. La tua unica opzione in questo caso è di rifiutare le risposte se impiegano troppo tempo (la soglia dipende da quanto è ammissibile la deriva).