포트 123: NTP (Network Time Protocol)

여기 흥미로운 사실이 있습니다: 여러분의 컴퓨터는 실제로 지금이 몇 시인지 모릅니다.

시계는 있습니다—초당 수백만 번 진동하는 수정 발진자가요. 하지만 그 수정에는 오차가 생깁니다. 모든 수정이 그렇습니다. 혼자 내버려 두면, 컴퓨터의 시계는 한 달에 몇 분씩 틀어지다가 결국엔 몇 시간씩 어긋나, 세상과 "지금"을 공유해야 하는 어떤 것에도 쓸모없어집니다.

시간은 컴퓨터가 가진 데이터가 아닙니다. 컴퓨터가 세상과 유지하는 합의입니다. 포트 123과 Network Time Protocol (NTP)은 그 합의가 이루어지는 방식입니다—수십억 개의 기기가 접속해 시계를 조정하고, 인터넷 전체에서 서로 수 밀리초 이내로 동기화를 유지합니다.

시계가 일치해야 하는 이유

시계가 몇 초 어긋나는 건 별로 중요하지 않다고 생각할 수 있습니다. 그런데 시간과는 전혀 관계없어 보이는 방식으로 갑자기 일이 망가지기 시작합니다.

보안 인증서가 작동을 멈춥니다. 모든 HTTPS 연결은 서버의 인증서가 지금 이 순간 유효한지 확인합니다—만료되지 않았는지, "아직 유효하지 않음" 상태가 아닌지요. 시계가 틀리면, 정상적인 웹사이트가 사기 사이트처럼 보입니다. 아니면 더 나쁘게—만료된 인증서가 유효한 것처럼 보이기도 합니다.

이중 인증이 실패합니다. 인증 앱에서 나오는 여섯 자리 코드? 시간 기반입니다. 그 코드는 30초 동안만 유효한데—어느 30초인지는 두 기기가 지금이 몇 시인지 동의하고 있느냐에 달려 있습니다. 시계가 5분 어긋나면, 앱이 보여주는 코드는 서버가 기대하는 코드와 절대 일치하지 않습니다. 올바른 비밀번호, 올바른 휴대폰, 모든 게 맞습니다. 하지만 기기와 서버가 "지금"이 언제인지 의견이 다르기 때문에 여전히 잠겨 있습니다.

분산 시스템이 스스로를 망가뜨립니다. 여러 서버가 같은 데이터를 처리할 때, 타임스탬프가 순서를 결정합니다. 어떤 쓰기 작업이 먼저 일어났는가? 어떤 트랜잭션이 우선해야 하는가? 서버들 간에 몇 초만 시간 차이가 나도 불가능한 상태가 발생합니다—서로 모순된 데이터, 잘못된 순서로 발생한 것처럼 보이는 트랜잭션, 인과율을 위반하는 것 같은 버그들이요.

로그가 허구가 됩니다. 보안 사고 이후, 무슨 일이 일어났는지 재구성해야 합니다. 서버 A는 14:32:07에 이벤트를 기록했습니다. 서버 B는 관련 이벤트를 14:31:58에 기록했습니다. B가 A보다 먼저 일어났을까요? 아니면 시계가 그냥 틀린 걸까요? 시계가 틀어져 있으면, 포렌식은 짐작에 의존할 수밖에 없게 됩니다.

시간의 계층 구조

NTP는 시간 출처를 "Stratum"이라는 계층으로 구성합니다. 소수의 권위 있는 출처에서 수십억 개의 기기로 정확한 시간을 분배하는 피라미드 구조입니다.

Stratum 0은 시간이 오는 근원입니다—원자시계, GPS 위성, 국가 연구소의 전파 신호. 이것들은 네트워크 장치가 아닙니다. 양자 현상이나 우주에서 오는 신호를 통해 실제 시간의 흐름을 측정하는 물리적 기기입니다.

Stratum 1 서버는 Stratum 0 출처에 직접 연결됩니다. 지붕 위의 GPS 수신기, 원자시계로의 케이블—이 서버들은 대학교, 정부, 주요 공급업체가 운영하는 인터넷의 기본 시간 출처입니다. 하나의 Stratum 1 서버가 수백만 클라이언트에게 시간을 제공할 수 있습니다.

Stratum 2 서버는 Stratum 1과 동기화되어 일반에게 서비스를 제공합니다. pool.ntp.org를 사용하도록 컴퓨터를 설정하면, 전 세계에 분산된 수천 개의 자발적으로 운영되는 Stratum 2 서버에 접속하는 것입니다.

Stratum 3부터 15까지는 추가 계층을 이루며, 각각 위 계층과 동기화됩니다. 여러분의 노트북은 아마 Stratum 3 또는 4일 것입니다—원자시계를 신뢰하는 서버를 신뢰하는 서버를 신뢰하는 셈이죠.

이 계층 구조는 권위 있는 출처가 과부하되는 것을 막습니다. 또한 중복성을 제공합니다—NTP 클라이언트는 여러 서버에 쿼리를 보내고 알고리즘을 통해 신뢰할 수 있는 출처를 가려냅니다. 하나의 서버가 틀리면, 나머지가 다수결로 이깁니다.

UDP 포트 123을 사용하는 이유

NTP는 UDP만 사용합니다—포트 123에서 송수신 모두. 이 선택은 의도적입니다.

시간 동기화는 빨라야 합니다. TCP의 핸드셰이크와 확인 응답은 지연을 발생시키는데, 시간을 정확하게 측정하려 할 때는 밀리초 단위의 네트워크 지연 하나하나가 중요합니다. UDP를 통해 NTP는 패킷의 왕복 시간을 정밀하게 측정하고, 실제 시간을 계산할 때 네트워크 지연을 보정할 수 있습니다.

NTP는 패킷 손실도 견딜 수 있습니다. 하나의 시간 쿼리가 사라지면, 클라이언트는 그냥 다시 물어봅니다. 유지해야 할 상태도, 재수립해야 할 연결도 없습니다. 프로토콜은 계속해서 "지금 몇 시인가요?"를 묻고 답변에 따라 조정할 뿐입니다.

증폭 공격 문제

NTP의 단순함은 무기가 되었습니다.

이 프로토콜에는 한때 monlist라는 디버깅 명령어가 있었는데, 마지막 600개 클라이언트에 대한 정보를 반환했습니다. 작은 요청 하나가 200배 더 큰 응답을 만들어낼 수 있었습니다.

공격자들은 이를 증폭 공격에 악용했습니다: 수천 개의 NTP 서버에 아주 작은 요청을 보내되, 출처 주소를 피해자의 IP로 위조하는 것입니다. 서버들은 응답합니다—공격자가 아닌 피해자에게—원래 요청보다 훨씬 큰 응답으로요. 이 방식으로 400 Gbps를 초과하는 트래픽 폭주가 발생한 사례도 있는데, 거의 모든 대상을 마비시킬 수 있는 양입니다.

NTP 서버들이 침해당한 것이 아닙니다. 그냥 요청받은 대로 한 것뿐입니다. 공격자는 단순히 요청자가 누구인지에 대해 거짓말을 했습니다.

현대 NTP 서버는 기본적으로 monlist를 비활성화합니다(버전 4.2.7p26¹에서 수정됨). 관리자는 서버가 이 명령에 응답하지 않는지 확인해야 합니다. 속도 제한과 신뢰할 수 있는 출처로만 NTP 쿼리를 제한하는 방화벽 규칙은 인프라가 공격에 악용되는 것을 막아줍니다.

신뢰 문제

초기 NTP에는 인증이 없었습니다. 클라이언트는 서버가 알려주는 시간을 그냥 믿었습니다.

네트워크를 신뢰할 수 있을 때는 괜찮습니다. 공격자가 트래픽을 가로챌 수 있을 때는 그렇지 않습니다. 네트워크 경로를 장악한 악의적인 행위자는 잘못된 시간을 주입할 수 있습니다—마음대로 인증서를 유효하거나 무효로 보이게 만들고, 감사 로그를 조작하고, 시간 기반 인증을 훼손할 수 있습니다.

**NTS (Network Time Security)**는 NTP에 암호화 인증을 추가합니다. 클라이언트는 자신이 정당한 서버와 통신하고 있는지 확인하고, 누군가 시간 동기화 메시지를 변조했는지 감지할 수 있습니다.

NTS는 TLS를 사용해 초기 신뢰를 확립한 뒤, AEAD (Authenticated Encryption with Associated Data)²로 이후의 시간 업데이트를 인증합니다. 수십 년간 NTP를 괴롭혀 온 중간자 공격 문제를 해결합니다.

2025년에 채택이 늘고 있습니다—Cloudflare는 공개 NTS 서비스를 제공하고³, IBM과 Juniper 같은 주요 업체들이 지원을 추가했으며, chrony 같은 구현체는 기본적으로 NTS를 포함합니다. 하지만 대부분의 기기와 공개 서버는 여전히 인증 없는 NTP를 사용합니다. 전환은 진행 중이지만, 아직 완료되지는 않았습니다.

시간을 올바르게 운영하기

최소 세 개의 NTP 출처를, 가능하면 네 개 이상을 설정하세요. NTP 알고리즘은 이상값을 감지하지만, 어떤 서버가 틀렸는지 파악하려면 충분한 출처가 필요합니다. 의견이 다른 서버 두 개만으로는 어느 쪽이 옳은지 알 방법이 없습니다. 세 개면 고장난 하나를 다수결로 이길 수 있습니다.

중요한 인프라의 경우, GPS에 동기화된 내부 Stratum 1 또는 Stratum 2 서버 운영을 고려하세요. 공개 인터넷 시간에 대한 의존도를 낮추고 정확도에 대한 통제권을 확보할 수 있습니다.

동기화 상태를 모니터링하세요. 클럭 드리프트는 인증 실패, 인증서 오류, 서로 연관 지을 수 없는 로그처럼 무언가가 고장날 때까지 눈에 보이지 않습니다. 드리프트가 임계값을 초과하거나 동기화가 완전히 실패하면 알림을 받도록 설정하세요.

모든 것의 기반이 되는 합의

포트 123은 데이터보다 더 근본적인 것을 전달합니다. 합의를 전달합니다—수십억 개의 기기가 끊임없이 "지금"이 언제인지에 대한 공유된 이해를 협상하는 것입니다.

그 합의는 깨질 때까지 보이지 않습니다. 그러면 시계가 일치하는 것에 은연중에 의존해 오던 모든 것들—보안, 인증, 데이터베이스, 로그—이 시간과는 관계없어 보이는 방식으로 무너지기 시작합니다.

NTP는 1985년부터 이 합의를 유지해 왔습니다. 이 프로토콜은 그것에 의존하는 대부분의 시스템보다 오래되었습니다. Stratum 계층 구조, UDP의 효율성, 신뢰할 수 없는 출처를 가려내는 알고리즘—이 모든 것은 너무나 근본적이어서 우리가 그 존재조차 잊어버리는 문제를 해결하기 위해 존재합니다: 제각각의 시계들이 시간이라는 공유된 허구에 동의하게 만드는 것입니다.

그 허구가 유지될 때, 모든 것이 작동합니다. 그렇지 않으면, 현실이 무너지기 시작합니다.

NTP와 포트 123에 대한 자주 묻는 질문

NTP는 왜 TCP 대신 UDP를 사용하나요?

시간 동기화는 네트워크 지연을 정밀하게 측정해야 하는데, TCP의 연결 오버헤드는 정확한 측정을 방해하는 가변 지연을 발생시킵니다. UDP를 사용하면 NTP는 패킷을 보내고, 왕복에 걸리는 시간을 정확히 측정하며, 실제 시간을 계산할 때 그 지연을 보정할 수 있습니다. 또한 패킷 손실에도 잘 대처합니다—쿼리가 사라지면 그냥 다시 물어봅니다.

NTP 동기화는 얼마나 정확한가요?

공개 인터넷에서 NTP는 일반적으로 수십 밀리초 이내의 정확도를 달성합니다. 전용 타임 서버가 있는 로컬 네트워크에서는 마이크로초 수준까지 정확도가 올라갈 수 있습니다. 제한 요인은 보통 네트워크 지연의 변동성입니다—네트워크 경로가 일정할수록, NTP가 지연을 더 정확히 측정하고 보정할 수 있습니다.

NTP를 통해 컴퓨터가 해킹될 수 있나요?

NTP 자체는 공격 표면이 크지 않지만, 두 가지 위험이 있습니다: 증폭 공격(NTP 서버가 다른 누군가를 공격하는 데 악용되는 경우)과 시간 조작(공격자가 잘못된 시간을 주입해 인증서 검증이나 인증을 훼손하는 경우). NTP 소프트웨어를 최신 상태로 유지하고, monlist 같은 레거시 명령을 비활성화하며, 지원되는 경우 NTS (Network Time Security)를 사용하면 이러한 위험을 줄일 수 있습니다.

NTP 서버가 다운되면 어떻게 되나요?

컴퓨터의 시계는 내부 발진기로 계속 작동하지만, 정확한 시간에서 서서히 벗어납니다. 얼마나 빨리 벗어나는지는 하드웨어에 따라 다릅니다—일반적인 드리프트는 하루에 몇 초입니다. 대부분의 NTP 클라이언트는 여러 서버로 설정되어 있어 자동으로 대체 서버로 전환합니다. 진짜 위험은 드리프트가 인증이나 인증서 문제를 일으킬 때까지 장애를 알아차리지 못하는 것입니다.

자체 NTP 서버를 운영해야 하나요?

개인 사용자라면 공개 NTP 풀로 충분합니다. 보안에 민감한 시스템을 운영하는 조직이라면, GPS 또는 권위 있는 출처에 동기화된 내부 NTP 서버를 운영하는 것이 더 나은 통제권을 제공하고, 공개 인프라에 대한 의존도를 낮추며, 정확도도 향상시킵니다. 시간 정확도가 업무 운영이나 보안에 영향을 미칠 때 이 투자는 충분한 가치가 있습니다.

출처