NTPに脆弱性
だそうなので、この際古いNTPサーバリプレースしちゃおうかみたいになったので、DNSレコード切り替えでいけないかなって検証したらやっぱりいけなかった。
用意した即席検証環境
- ntpサーバ１: CentOS 6.6
- ntpサーバ２: CentOS 5.5
- ntpクライアント: 6.6
検証内容
- time.tekito.orgのAレコードににntpサーバ１のIPを登録 TTLは60sec
- クライアントのntpサーバをサーバ１(time.tekito.org)に向ける
- サーバ１およびサーバ２で
tcpdump実施 - DNSを切り替えてtime.tekito.orgをサーバ２に向ける
-
tcpdumpの内容を確認
結果
サーバ１でのtcpdumpの模様
# tcpdump -n -p udp and src host XXX.XXX.XXX.XXX # コマンドが雑！
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
12:35:44.491135 IP XXX.XXX.XXX.XXX.ntp > YYY.YYY.YYY.YYY.ntp: NTPv4, Client, length 48
12:36:50.521204 IP XXX.XXX.XXX.XXX.ntp > YYY.YYY.YYY.YYY.ntp: NTPv4, Client, length 48
12:39:01.554517 IP XXX.XXX.XXX.XXX.ntp > YYY.YYY.YYY.YYY.ntp: NTPv4, Client, length 48
12:43:21.571990 IP XXX.XXX.XXX.XXX.ntp > YYY.YYY.YYY.YYY.ntp: NTPv4, Client, length 48
# ここでDNSレコードの切り替えを実施(12:46)
12:52:00.652235 IP XXX.XXX.XXX.XXX.ntp > YYY.YYY.YYY.YYY.ntp: NTPv4, Client, length 48 <- 引き続きリクエストに応答しているよ
てな感じでダメだった。なおクライアント側でntpdを再起動したところ直ぐにサーバ２を参照し始めた。
それをふまえてサーバ２でのtcpdumpの模様
# tcpdump -n -p udp and src host XXX.XXX.XXX.XXX
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
# ここでクライアント側のntpdを再起動(12:58)
12:58:24.796520 IP XXX.XXX.XXX.XXX.ntp > ZZZ.ZZZ.ZZZ.ZZZ.ntp: NTPv4, Client, length 48 <- すぐ来た
12:59:30.864001 IP XXX.XXX.XXX.XXX.ntp > ZZZ.ZZZ.ZZZ.ZZZ.ntp: NTPv4, Client, length 48
13:00:36.862077 IP XXX.XXX.XXX.XXX.ntp > ZZZ.ZZZ.ZZZ.ZZZ.ntp: NTPv4, Client, length 48
13:01:41.861133 IP XXX.XXX.XXX.XXX.ntp > ZZZ.ZZZ.ZZZ.ZZZ.ntp: NTPv4, Client, length 48
結論
ntpサーバのDNSレコードを切り替えたらクライアント側のntpdを再起動しないといけない。未確認だが起動時に読み込んだ設定をずっと持ち続けると思われる。多数のクライアントが存在する場合のntpサーバリプレースでは、DNSを切り替えるのはあまり得策ではなさそう。