NTP (Network Time Protocol)

¿Qué es NTP?

El Network Time Protocol (NTP) es un protocolo de red definido originalmente en el RFC 958 (1985) y actualizado en su versión actual NTPv4 por el RFC 5905 (2010). Su función es sincronizar los relojes de todos los dispositivos conectados a una red —servidores, ordenadores, dispositivos móviles, routers, sistemas de fichaje— con fuentes de tiempo de referencia de alta precisión.

La importancia de NTP trasciende la comodidad operativa de tener todos los dispositivos en la misma hora. En el contexto de la informática forense, el derecho laboral digital y la seguridad informática, NTP es el fundamento técnico que determina si los timestamps de un sistema pueden ser considerados fiables como evidencia.

Arquitectura de Estratos NTP

NTP organiza las fuentes de tiempo en una jerarquía de estratos (0 a 16, según el RFC 5905), donde el estrato 0 representa la referencia de máxima precisión y cada nivel superior añade incertidumbre:

Precisión por Estrato

La precisión que ofrece NTP depende del estrato y de la calidad de la conexión de red:

• Estrato 1 con red local: precisión de microsegundos
• Estrato 2 sobre internet: precisión de milisegundos (1-50 ms)
• Estrato 3 sobre internet: precisión de decenas de milisegundos

Para la mayoría de aplicaciones forenses y de registro horario, una precisión de 1 segundo es más que suficiente. Los sistemas bien configurados sobre internet consiguen habitualmente una precisión inferior a 10 milisegundos.

Servidores NTP de Referencia en España

Real Instituto y Observatorio de la Armada (ROA)

El servidor de referencia oficial en España es hora.roa.es, operado por el Real Instituto y Observatorio de la Armada, que es la institución designada por el Ministerio de Defensa y el Real Decreto 1308/1992 para la conservación y difusión de la Hora Legal Española.

El ROA mantiene su hora sincronizada con el Tiempo Universal Coordinado (UTC) mediante relojes atómicos de cesio y comparaciones continuas con el Bureau International des Poids et Mesures (BIPM). La incertidumbre típica de hora.roa.es es inferior a 1 microsegundo respecto a UTC.

Para aplicaciones con implicaciones legales, hora.roa.es es la mejor referencia disponible por NTP. Con una precisión que conviene declarar en el informe: el ROA califica su NTP por internet como servicio no certificado, y los servidores públicos se apoyan en GPS con entrada de UTC(ROA), no en el conjunto de relojes que materializa la escala. Cuando hace falta una hora oponible, lo que se usa es un sello de tiempo cualificado de un prestador de servicios de confianza, no una sincronización NTP. Sigue siendo la mejor práctica técnica y la que mayor respaldo documental ofrece ante un tribunal.

## /etc/ntp.conf - Configuración recomendada para España

## Servidor primario: ROA (hora legal española)
server hora.roa.es iburst prefer

## Servidores secundarios de respaldo
server 0.es.pool.ntp.org iburst
server 1.es.pool.ntp.org iburst
server 2.es.pool.ntp.org iburst

## OJO: `panic 0` NO fija un umbral de 1 segundo: DESACTIVA la comprobación de
## cordura, cuyo valor normal son 1000 s, y hace que ntpd acepte un salto de
## cualquier tamaño. Solo tiene sentido en el primer arranque de una máquina con
## el reloj muy desviado. En un servidor de fichajes es justo lo contrario de lo
## que se quiere: la traba es la que impide un salto de horas.
# tinker panic 0

## Guardar registro de sincronizaciones
driftfile /var/lib/ntp/ntp.drift
logfile /var/log/ntp.log

## Registrar estadísticas de sincronización (clave para forense)
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

El pool español: es.pool.ntp.org

La zona española del NTP Pool Project agrupa servidores voluntarios de estrato 2 y 3 en España. (Cuidado con «ntp.es»: no es un operador de NTP, es un dominio aparcado.) Son adecuados para sincronización general, pero para aplicaciones forenses se recomienda incluir hora.roa.es como servidor primario.

NTP y la Validez Forense de los Timestamps

Por Qué los Timestamps Sin NTP No Son Fiables

Un sistema que no usa NTP depende de su reloj interno (RTC, Real-Time Clock), que puede desviarse a razón de varios segundos por día. Un servidor sin NTP durante un año puede tener un reloj adelantado o atrasado en varios minutos. Consecuencias forenses:

1. Los logs de este sistema no son comparables con los de otros sistemas
2. Cualquier reconstrucción de la secuencia de eventos es poco fiable
3. Determinar si un timestamp se generó en el momento declarado exige contrastarlo con fuentes externas —logs de otro sistema, registros del operador, cabeceras de correo—, porque el propio equipo ya no lo acredita

Más grave aún: cualquier administrador del sistema puede cambiar la hora del sistema en cualquier momento, generando logs y registros con fechas y horas completamente falsas, sin que esta manipulación deje rastro si no hay comparación con fuentes externas.

Cómo NTP Actúa Como Salvaguarda Forense

Con NTP activo y correctamente configurado:

1. Trazabilidad a fuente oficial: Cada timestamp del sistema es trazable matemáticamente a la hora del servidor NTP y, a través de este, a UTC y al ROA.
2. Detección de manipulación: Con NTP activo y su comprobación de cordura intacta, un cambio de hora se corrige solo; pero eso deja de valer si el servicio puede pararse, que es exactamente lo que hace un administrador con permisos. Los logs de NTP registran esta corrección, evidenciando el intento de manipulación.
3. Coherencia multiservidor: Todos los sistemas de la organización comparten la misma referencia temporal, permitiendo correlación cruzada de logs.

SNTP vs NTP: Diferencias Relevantes

El Simple Network Time Protocol (SNTP) es una versión simplificada de NTP, definida en el RFC 4330. Está presente en muchos dispositivos embebidos, sistemas IoT, y aplicaciones ligeras.

Para aplicaciones con implicaciones legales —sistemas de registro horario certificado, servidores de sellado de tiempo, plataformas de evidencia digital— debe usarse NTP completo (ntpd o chrony), no SNTP.

Configuración y Verificación en Sistemas de Fichaje

Verificar Sincronización NTP Activa

## Linux - con timedatectl (systemd)
timedatectl status
## Verificar: "NTP synchronized: yes" y "NTP service: active"

## Linux - con ntpq
ntpq -p
## La fila con asterisco (*) es el servidor activo preferido
## "offset" debe ser pequeño (< 100 ms para forense)
## "reach" debe ser 377 (todas las últimas 8 consultas exitosas)

## Linux - con chronyc
chronyc tracking
## Verificar: "Reference ID" (debe ser hora.roa.es o similar)
## "System time offset": debe ser < 1 segundo

## Windows - verificar sincronización
w32tm /query /status
## Verificar: "Source" y "Last Successful Sync Time"

Auditoría Forense de Sincronización Histórica

Los logs de NTP permiten a un perito forense verificar retrospectivamente si el reloj del sistema estaba sincronizado durante un período determinado:

## Ver historial de sincronizaciones (ntpd)
cat /var/log/ntp/peerstats | grep "hora.roa.es"

## Con chrony: historial de correcciones
chronyc sourcestats -v

## Buscar correcciones grandes (> 1 segundo) que podrían indicar manipulación
grep "step" /var/log/syslog | grep -i "ntp\|chrony"

## Ver ajustes del reloj del sistema registrados por kernel
dmesg | grep -i "clock\|ntp\|time"

Si los logs de NTP muestran que el servicio estaba detenido o que hubo correcciones bruscas de varios minutos en períodos concretos, esto puede indicar manipulación del reloj del sistema durante esos intervalos.

Marco Legal en España

La obligación implícita de utilizar fuentes horarias fiables en sistemas con efectos jurídicos se desprende de varias normas:

• Real Decreto 1308/1992: designa al Real Instituto y Observatorio de la Armada como entidad responsable de la conservación y difusión de la Hora Legal Española, estableciendo hora.roa.es como la fuente oficial de referencia para cualquier sistema que deba acreditar la hora con efectos legales en España.
• Artículo 34.9 del Estatuto de los Trabajadores (redacción RD-ley 8/2019): exige que el registro horario incluya el horario “concreto” de inicio y fin de jornada. Un sistema cuyos relojes no están sincronizados con fuentes oficiales no puede ofrecer esta concreción con garantías.
• Reglamento eIDAS (UE 910/2014), artículo 42: exige que el sello de tiempo cualificado esté basado en “una fuente de tiempo precisa vinculada al Tiempo Universal Coordinado (UTC)”. Las TSA acreditadas usan NTP de Estrato 1 como parte de su infraestructura de certificación.
• Criterio Técnico 101/2019 de la ITSS: es el instrumento que fija cómo actúa la Inspección en materia de registro de jornada. Exige que el registro refleje el horario concreto y sea verificable, y un sistema cuyos relojes no están sincronizados no puede sostener esa concreción ante el inspector.

En la práctica, aunque ninguna norma cita explícitamente NTP como requisito, la jurisprudencia del Juzgado de lo Social en materia de valoración de registros digitales ha comenzado a considerar la ausencia de sincronización horaria verificable como factor que reduce el valor probatorio del registro.

Implicaciones en el Registro Horario Laboral

Para que un sistema de registro horario digital genere timestamps válidos desde el punto de vista forense, debe cumplir:

1. NTP activo y configurado: El servidor que gestiona los fichajes debe tener NTP sincronizando con fuentes de Estrato 1 o 2 de referencia.
2. Logs de NTP conservados: Los logs de sincronización deben conservarse durante el mismo período que los registros de jornada (4 años), para demostrar retroactivamente que el reloj era fiable.
3. Alertas por desincronización: El sistema debe alertar si NTP falla durante más de un umbral definido (ej. 30 segundos), generando un registro de la anomalía.
4. Sellado de tiempo externo: Idealmente, el timestamp NTP del sistema se usa como base para solicitar un sello de tiempo certificado por una TSA, que proporciona la capa adicional de garantía independiente.

Caso Práctico: Detección de Manipulación de Reloj

Escenario

Una empresa es inspeccionada por la ITSS. Los registros horarios muestran que todos los empleados fichaban dentro del horario pactado, sin una sola hora extraordinaria en 6 meses. El inspector solicita acceso al sistema.

Análisis Forense

El perito informático contratado por el sindicato examina el servidor:

1. Logs de NTP: El servicio NTP del servidor fue desactivado durante 3 períodos de entre 15 y 45 minutos, siempre entre las 17:00 y las 19:00 horas. Durante esos períodos, los logs de NTP muestran “NTP service stopped” seguido de “clock set manually: +1h 45m”.

2. Correlación con registros: Los períodos sin NTP coinciden exactamente con los únicos días del mes en que el sistema detectó trabajo fuera de horario en los logs de acceso a la aplicación corporativa (que no pasaba por el sistema de fichaje).

3. Análisis de los logs de autenticación: El único usuario que accedió al sistema durante esos períodos era el administrador de sistemas, cuya jornada laboral estaba documentada en papel (sin sistema digital).

4. Conclusión pericial: La desactivación de NTP durante la tarde y el ajuste manual del reloj hacia atrás permitieron que el fichaje de salida se registrara con una hora anterior a la real, de modo que las horas extraordinarias aparecieran dentro del horario normal.

Qué sostiene el análisis: que el reloj se alteró, cuándo, en qué sentido y quién tenía acceso en esos intervalos. Qué no: el resultado del expediente. En este terreno la Inspección propone el acta y la autoridad laboral resuelve —y la manipulación del registro horario encaja en el artículo 7.5 de la LISOS—, pero eso lo decide el procedimiento, no el dictamen. Si además hubiera indicios de posible falsedad documental.

Conclusión

NTP es el componente silencioso pero esencial que determina si los timestamps de cualquier sistema digital pueden considerarse evidencia fiable. En el contexto de la informática forense, el derecho laboral digital y la seguridad informática, la correcta configuración de NTP —con servidores de referencia acreditados, logs conservados y alertas por desincronización— es un requisito técnico no negociable.

Un sistema de registro horario sin NTP no genera evidencia: genera datos con fecha que no pueden verificarse de forma independiente. Un sistema con NTP correctamente configurado y auditado transforma cada fichaje en un dato temporalmente trazable a la hora legal española.

Referencias y fuentes

1. RFC 5905 — Network Time Protocol Versión 4: Protocol and Algorithms Specification. Define los estratos (0-16, con MAXSTRAT = 16 para «no sincronizado») y los algoritmos de selección.
2. NTP Pool Project — zona de España, es.pool.ntp.org. El pool español real, con su recuento de servidores activos.
3. Real Instituto y Observatorio de la Armada — hora legal. El ROA es el organismo que conserva y difunde la hora legal española; su servicio NTP por internet consta como no certificado.
4. man ntp.conf — la directiva tinker panic: el umbral normal son 1.000 s y el valor 0 desactiva la comprobación, aceptando un salto de cualquier tamaño.
5. LISOS, art. 7.5 — infracción grave en materia de registro de jornada. boe.es

Última actualización: 29 de agosto de 2026 Categoría: Técnico Código: EXT-016