NTP의 배경
NTP는 델라웨어 대학의 David L. Mills가 설계했고 1985년 이전부터 운영된 것으로 알려진, 지금도 쓰이는 가장 오래된 인터넷 프로토콜 중 하나입니다(위키백과 기준). 현재의 NTPv4는 2010년 RFC 5905로 규정되었고 NTPv3와 하위 호환됩니다. 1992년에는 같은 패킷 형식과 포트를 쓰되 정교한 필터링·보정 알고리즘을 생략한 간이 버전인 SNTP가 정의되었습니다. 정확도가 중요한 곳에서는 SNTP 소스를 시간 원천으로 삼지 말라는 조언이 있습니다.
오프셋과 지연은 어떻게 계산하나
RFC 5905는 한 번의 요청·응답에서 네 개의 시각을 기록합니다. T1은 클라이언트가 요청을 보낸 시각, T2는 서버가 요청을 받은 시각, T3는 서버가 응답을 보낸 시각, T4는 클라이언트가 응답을 받은 시각입니다. 이때 서버 시계와 내 시계의 차이(오프셋)와 왕복 지연은 다음과 같습니다.
- 오프셋 θ = ((T2 − T1) + (T3 − T4)) / 2
- 왕복 지연 δ = (T4 − T1) − (T3 − T2)
오프셋이 음수이면 내 시계가 서버보다 앞서 있다는 뜻입니다. 아래 예시는 모두 가상 예시이며 단위는 밀리초(ms), 값은 node로 검산했습니다.
| 상황 | T1, T2, T3, T4 | 계산 결과 |
|---|---|---|
| 시계가 정확하고 가는 길과 오는 길이 같음(각 40ms, 서버 처리 2ms) | 1000, 1040, 1042, 1082 | 오프셋 0, 지연 80 |
| 내 시계가 500ms 앞섬(편도 20ms, 서버 처리 2ms) | 1000, 520, 522, 1042 | 오프셋 −500, 지연 40 |
| 시계는 정확하지만 가는 길 30ms, 오는 길 50ms로 비대칭(서버 처리 2ms) | 0, 30, 32, 82 | 오프셋 −10(실제 0), 지연 80 |
세 번째 행이 핵심입니다. 두 방향의 지연이 같다고 가정하고 계산하기 때문에, 경로가 비대칭이면 시계가 정확해도 오프셋에 오차가 생깁니다. 이 오차는 왕복 지연의 절반(여기서는 40ms)을 넘지 않습니다. 위키백과가 "비대칭 경로와 혼잡으로 100ms 이상의 오차가 생길 수 있다"고 한 이유가 이것입니다.
스트라텀 정리
| 스트라텀 | 의미 |
|---|---|
| 0 | 원자시계·GNSS 같은 기준 시계 (패킷 값 0은 RFC에서 "미지정 또는 무효") |
| 1 | 기준 시계에 직접 연결된 1차 서버(RFC 예: GPS 수신기를 갖춘 서버) |
| 2~15 | NTP로 상위 서버에 동기화한 2차 서버 |
| 16 | 동기화되지 않음 |
스트라텀 n에 동기화된 서버는 n+1이 됩니다. 숫자는 기준 시계까지의 단계 수일 뿐이어서 품질이나 신뢰성을 그대로 보장하지는 않습니다(위키백과 기준).
실제 사례
사례 1. 2014년 약 400Gbps NTP 증폭 공격 (Cloudflare 보고)
2014년 2월 Cloudflare는 특정 대상을 겨냥한 공격이 최대 400Gbps에 육박했다고 기술 블로그에 공개했습니다. 공격에는 1,298개 네트워크의 NTP 서버 4,529대가 동원되었고 서버당 평균 약 87Mbps를 보냈습니다. 핵심은 NTP의 monlist 명령(최근 접속한 클라이언트 최대 600개의 IP를 돌려주는 기능)이었습니다. 목록이 가득 찼을 때 응답이 요청의 약 206배 크기가 될 수 있어, 위조된 출발지 주소로 작은 요청을 보내면 피해자에게 훨씬 큰 응답이 쏟아집니다. Cloudflare는 공격을 완화했지만 트래픽이 자사 모든 데이터센터에 도달했고 유럽 일부에서 네트워크 혼잡이 있었다고 밝혔으며, 관리자에게 monlist를 끄고 BCP38(출발지 주소 위조 차단)을 적용하라고 권고했습니다. 배울 점은 공격자가 NTP 서버를 해킹한 것이 아니라 열려 있는 기능을 이용했다는 것입니다.
사례 2. CISA 경보 TA14-013A (2014)
미국 CISA(당시 US-CERT)는 2014년 1월 경보에서 NTP 증폭 공격을 설명했습니다. 공개된 NTP 서버에 출발지를 피해자로 위조한 monlist 요청을 보내면 서버의 응답이 피해자에게 가며, 응답은 정상 서버에서 온 합법적 데이터라 걸러내기 어렵다는 내용입니다. 경보는 ntpd 4.2.7 이전 버전이 기본적으로 취약하다고 밝히고, 공개 서버를 4.2.7 이상으로 올리거나 불가능하면 ntp.conf의 restrict default 줄에 noquery를 추가하라고 안내했습니다. 증폭 배수 수치는 경보에 명시되지 않았습니다.
사례 3. NTP 풀 프로젝트 (공개 시간 서버)
pool.ntp.org는 자원봉사자가 제공하는 공개 시간 서버 모음입니다. 0~3.pool.ntp.org 이름은 내 위치에서 가까운 서버 집합을 무작위로 돌려주며 약 한 시간마다 바뀝니다. 풀 운영 측은 사업이나 인명이 정확한 시간에 달린 시스템은 공급업체의 신뢰할 수 있는 시간 서비스를 쓰라고 안내하고, 서버는 최대 4대까지만 설정하며 부하를 늘리는 burst 같은 설정은 피하라고 권합니다. ISP나 가까운 시간 서버가 있으면 그것을 쓰는 편이 낫다는 안내도 있습니다.
직접 확인하고 설정해 보기
- 윈도우: 날짜 및 시간 설정의 인터넷 시간에서 서버를 pool.ntp.org로 지정하고 지금 업데이트를 눌러 볼 수 있습니다. 도메인에 가입된 PC는 개별 설정이 제한될 수 있습니다.
- 시간은 맞는데 시간대가 틀리다면 NTP의 문제가 아닙니다. NTP는 시간대를 전달하지 않으므로 운영체제의 시간대 설정을 확인하세요.
- 회사처럼 장비가 많다면 내부 서버 한 대를 상위에 동기화하고 나머지는 그 서버를 바라보게 하는 방식이 외부 서버 부하를 줄입니다(풀 운영 측 권고).
- NTP 서버를 직접 운영한다면 인터넷에 열린 서버의 monlist 응답 여부를 점검하고, 업데이트와 접근 제한을 적용하세요. 이 점검은 반드시 자신이 관리하는 서버에만 하세요.
흔한 오해와 정정
- 오해: NTP는 시간대와 서머타임까지 맞춰 준다. 실제: NTP는 시간대 정보를 전송하지 않고 UTC 기준 시각만 다룹니다.
- 오해: 스트라텀 숫자가 작을수록 항상 더 정확하다. 실제: 스트라텀은 기준 시계까지의 단계 수이고 품질을 보장하는 지표가 아닙니다.
- 오해: NTP 증폭 공격은 NTP 서버가 해킹되어서 일어난다. 실제: 열려 있던 monlist 기능과 위조 출발지 주소를 이용한 것입니다.
- 오해: 시간이 몇 초 틀려도 문제없다. 실제: 인증서 유효기간 검증이나 시간 기반 일회용 비밀번호처럼 시간에 민감한 기능은 오차에 영향을 받을 수 있습니다.
한계와 앞으로의 과제
NTP는 비대칭 경로 같은 네트워크 조건에 따라 정확도가 달라지며, 인터넷에서는 보통 수십 ms 이내, 이상적인 LAN에서는 1ms 이상의 정확도가 가능하다고 알려져 있습니다. 이보다 더 정밀한 동기화가 필요한 분야에는 별도의 방식이 쓰입니다. 또 NTP 타임스탬프는 1900년 1월 1일을 기준으로 32비트 초를 쓰기 때문에 2036년 2월 7일에 첫 번째 롤오버가 일어납니다(위키백과 기준). 윤초를 처리하는 방식도 환경마다 달라, Google·AWS·Facebook은 24시간에 걸쳐 나눠 조정하는 윤초 스미어링을 쓴다고 알려져 있습니다. 이 글은 일반 정보이며 구체적인 서버 설정은 사용하는 소프트웨어의 공식 문서를 확인하세요.
DDoS 공격이 궁금하다면
NTP 증폭 공격을 포함한 여러 디도스 공격 유형이 궁금하다면 DDoS 공격 종류와 방어 방법 완전정복도 확인해보세요.
함께 읽으면 좋은 가이드
정확한 시간이 왜 인증서 검증에 중요한지 더 알고 싶다면 TLS 핸드셰이크로 알아보는 HTTPS 연결 원리도 참고해보세요. NTP가 쓰는 UDP의 특징은 TCP와 UDP 차이 가이드, 123번 포트 차단 같은 설정은 방화벽 기초 가이드에서 이어 읽을 수 있습니다.
자주 묻는 질문
컴퓨터 시간이 안 맞으면 실제로 어떤 문제가 생기나요?
대표적으로 HTTPS 사이트 접속 시 인증서 오류가 발생하거나, 2단계 인증(OTP) 코드가 계속 틀린 것으로 처리되거나, 여러 서버의 로그를 시간순으로 비교하기 어려워지는 등의 문제가 생길 수 있습니다.
스마트폰도 NTP로 시간을 맞추나요?
네, 대부분의 스마트폰은 설정에서 "네트워크 제공 시간 사용" 같은 옵션을 켜두면 통신사 네트워크나 인터넷을 통해 자동으로 시간을 동기화합니다. 이 옵션을 꺼두면 기기 자체 시계에만 의존하게 되어 시간이 서서히 어긋날 수 있습니다.
NTP와 SNTP는 무엇이 다른가요?
SNTP는 NTP와 같은 패킷 형식과 포트를 쓰지만 NTP의 정교한 필터링·보정 알고리즘을 생략한 간이 버전입니다. 정확도가 중요하다면 SNTP 소스에 동기화하는 것은 권장되지 않습니다(위키백과 기준).
NTP 서버를 여러 개 지정하는 이유는 무엇인가요?
여러 서버의 응답을 비교하면 유난히 튀는 값을 걸러낼 수 있기 때문입니다. 다만 풀 운영 측은 서버를 4대 이하로 쓰라고 권고합니다.
방화벽에서 UDP 123번을 막으면 어떻게 되나요?
NTP 응답이 오지 않아 시간 동기화가 실패하고 시계가 서서히 어긋날 수 있습니다. 내부 시간 서버만 허용하는 식으로 필요한 통신만 열어 두는 것이 일반적인 접근입니다.