福岡大学のNTPサーバーに1.1.1.1からNTPリクエストパケットが飛んでいる 30
ストーリー by hylom
そんな機器があるのか 部門より
そんな機器があるのか 部門より
福岡大学の公開NTPサーバーについてはたびたび話題となっているが（過去記事：福岡大学NTPサーバの混雑解消にご協力を、TP-Linkの無線LANルーターなどで高頻度でNTPサーバーにリクエストを投げる設定が発覚し問題に、福岡大学、公開NTPサーバーを停止する方針を決定）、最近「1.1.1.1」というIPアドレスからこのNTPサーバーに定期的にリクエストが来ているという（Togetterまとめ）。
「1.1.1.1」は現在ではAPNICとCloudflareが共同で立ち上げたパブリックDNSサービスで使われているが（過去記事）、今回のトラブルはこのサービスが原因では無いようだ。内部ネットワークなどで「1.1.1.1」というIPアドレスを設定している機器があり、不適切な設定などが原因でその機器に関連するパケットがネットワーク外に出て問題を起こしていると見られている。
1.1.1.1 (スコア:2)
イチイチうるせーなぁって感じですかね。
関連コメント (スコア:1)
あのぉ、1.1.1.1 は、わたしが使っている IP アドレスですので勝手に使わないでください。
https://srad.jp/comment/3386741 [srad.jp]
と、何か関係が・・。
Re: (スコア:0)
>1.1.1.1は、Cisco Wireless LAN Controllerとバッティングしてるらしい。
Re:関連コメント (スコア:1)
Atresiaの認証VLANはデフォルトだと1.1.1.1を自称してたような
見たような聞いたような・・・
itinoe
Re: (スコア:0)
こんなに簡単に詐称できたら、犯罪捜査みたいな社会インフラが破壊されてしまうんじゃないの？NTPの仕様がおかしいのか。
Re:関連コメント (スコア:2, 参考になる)
NTPじゃなくてUDPの仕様でございます
Re:関連コメント (スコア:1)
送信元IPアドレスの詐称は、可能。
まずは、この辺り [wikipedia.org]を読んでみたら?
それができたら、IPスプーフィング [wikipedia.org]を読んでみると良い。
Re:関連コメント (スコア:1)
でも、ネットワークの境界で、内側から来たパケットの送信元IPアドレスが、内側のネットワークとしてありえない場合は、通さないようにする [nic.ad.jp]というのは、ごく一般的な運用だと思います。
#20年ほど前の時点で、少なくともOCNはそういう運用してました。
#ネットワーク回線を二重化した時に発見。別回線の方で割り当てられたIPアドレスを送信元としたパケットはOCN回線からはインターネットに出て行かなかった。
#別回線(プロバイダは失念)の方はOKだったし、OCNな契約2回線(OCNエコノミーとフレッツ)もOKだった
当時はちょっと「OCNは制限キツい運用してるなー」って思いましたが、その後の「不正なIPアドレスを使った攻撃」の流行っぷりを見ると、もはやそういうフィルタリングは常識レベルであり、今時やってなかったら「DoSに荷担してる」って言われても反論できないレベルじゃないかと思いますね。
Re:関連コメント (スコア:1)
その通り。
普通のプロバイダだとやってるんじゃないかな。
プロバイダレベルでなくても、最近はいろんなところでセッションを管理してるので、上り下りの経路が違ったりすると通信できなくなるよ。
Re: (スコア:0)
このあたりの設定漏れをあぶり出す効果もあったってわけだ。
表向きの名目とは違うところでばっか成果出してんなコレ。
Re: (スコア:0)
一方的な詐称は可能だが、詐称したＩＰでの通信は不可能
Re:関連コメント (スコア:1)
その通り。
だから、誰も福岡大学NTPサーバと、1.1.1.1が正常な通信を行っている、とは言ってないよね。
そういうわけで、送信元IPアドレスは、詐称可能。
ただ、詐称して正常な通信ができるか、っていうと、普通はできない。
そういうことね。
Re: (スコア:0)
正確にはUDPは可能でしょ。
NTPなら送受信があるけど、SyslogやSNMP Trapみたいなのは
送信のみで成立しちゃうから、安易に外部からのSyslog受け付けてるサーバとか危ないよねって・・・
Re: (スコア:0)
応答が見えなくてもシーケンス番号がわかれば憶測で応答を返せるケースも有ってそういうのではTCPも出来るし、
経路上でスニッフィングできれば…いやそれだと経路上から流し込めばいいだけか。
通信しなくても(DMS Amp等)DDoS踏み台ならそれでいけるし、
TCPに対するSYN Flood攻撃でも攻撃元の隠蔽に使ったり。
詐称パケットがネット上に流れるだけで十分リスクは有るのです。
Re: (スコア:0)
はがきも封筒も郵便は重要な社会インフラだけど、差出人はデタラメでも届くのは届くよ。返ってはこないけど。投函ポストも別に自分の街のものを使わなきゃいけない訳じゃないし。
Re: (スコア:0)
NICに8.8.8.8を付与すれば、君もGoogleになれるよ！（犯罪教唆）
Re: (スコア:0)
で、「ここに8.8.8.8があるぞ!」って、どうやってみんなに伝えるの？とマジレス。
おかしな自動設定が進みすぎたLAN内なら間違えてくれる可能性あり？
古い大きい組織が、内部ネットワークに「取得してもいないグローバルIPアドレス」を使ってた話がありましたっけ。
外部と通信しないなら、仕様上は何を使おうと自由なんだけど、「やっぱりネットに繋げないと」となれば、当然再設定にどえらいコストが発生します。
Re: (スコア:0)
1990年代でRFC 1597も無かったころには、外部との接続がないことをいいことに好き勝手なことをやっていた祖式はいくらでもあったからなあ。
Re: (スコア:0)
情報どうもです。くだんのRFCは1994年に出たんですね。
ちなみに外部接続との件は21世紀になってから聞いた気がします。
Re: (スコア:0)
今回の場合はみんなに伝えてないよ。
そう自称するパケットがインターネット上に流れ出てきただけで、そいつに返答しようとしてもCloudflareのほうに流れ込む。
DNS Amp攻撃とかと同じような構図だね。普通はありえない送信元だと通さないんだけど、その設定に漏れがあるとこうなる。
CloudflareのDNSを使えるように設定したつもりで詐称も可能な状態になっちゃったネットワーク内に居た、
プライベートのつもりで1.1.1.1を名乗ってたノードからの通信が意図せず偽装状態になった、と。
結構いっぱいあるんだろうな、そういうフィルタの穴は……
Re: (スコア:0)
IPの仕様。送り元の詐称が不可能な仕様を盛り込もうとするととんでもないコストがかかる一方、送り元を詐称できても大した悪さはできないから、そこは諦められてる。
そもそもインターネットは、どこの馬の骨とも分からん奴らからのパケットがいくらでも飛んでくる、という前提なので、
仮に、送り元が詐称できないインターネットを作ったとしても、あんまり意味が無い。
・今の普通のインターネット
受け取ったパケットをどこの誰が送ってきたのか分からない。
送り元が詐称されてるかもしれないのでホントに分からない。
・詐称不能なインターネット
受け取ったパケットをどこの誰が送ってきた
Re: (スコア:0)
詐称できることより、間に挟まったルータがみんな「送信元を間違えた、インチキなIPパケットを捨て」てくれないことが問題な気がする。
間違いはあることなんだし、さりとて到達先がぜんぶ自分で判別しろ、というのも酷な話だから。
ついでに質問。
ASから漏れたら、真偽は本質的に判定不能、という理解であってる？
役人ACの福岡大学の想い出(オフトピ:-1) (スコア:0)
福岡大学と言えば、
役人ACとしては、国家公務員採用I種試験の一次試験の会場。
3年生の時に、有志の勉強会に誘われて受け行き、
4年生の時は研究室の仲間と受けに行き、
以後は「提示延期」を繰り返し、独りで受けに行った九州の田舎の大学生の想い出。
だからサンプルには (スコア:0)
実際に有効な値を使うなっていつも言ってるじゃないですかー！
ほんと軽い気持ちで、test.comとかにデータ送っちゃう人多過ぎ。
悪意ある人がドメイン取ってデータ収集に活用してたらどうすんのかと。
Re: (スコア:0)
1.1.1.1って以前は割り当てられないはずのアドレスじゃなかったっけ？
Re: (スコア:0)
Re: (スコア:0)
2000年～2010年ぐらいの間でIPアドレスの枯渇問題で、かつて予約されていたIPアドレスの予約が解除されて割り当てられたものは多い。
14.0.0.0/8,24.0.0.0/8,39.0.0.0/8,128.0.0.0/16,191.255.0.0/16なんかもそうだしね。
最近は、正式な許可もなく勝手に使われているIPアドレスなんかも、利用者を摘発してクレームをつけるとともに、正規の割り当てが加速している。
そうでもしないと、割り当てることができないという現実がある。
Re: (スコア:0)
example.com
example.net
example.org
*.example
*.invalid
*.test
*.テスト
*.localhost
localhost
127.0.0.0/8
192.0.2.0/24
198.51.100.0/24
203.0.113.0/24
このあたりならtest.comみたいなのよりかは安全ではあるが…
IPアドレスブロックは127.0.0.0/8以外はそのうち予約が解除になっちゃう可能性もあるかな？
Re:だからサンプルには (スコア:1)
example.co.jp
example.ne.jp
example.jp
example0.jp 〜 example9.jp
も例示に使えるとありますね。 https://jprs.jp/faq/use/ [jprs.jp]
でもドメイン名の例示に使えるのと、そのドメイン名を実際に指定して通信が発生しても「安全」なのとは、ちょっと違うような…
Re: (スコア:0)
test.comみたいなのよりかは安全、なだけですね。
TLDの奴は名前解決されない保証があるのか無いのかよく分からん…
ローカルホスト系のやつしか安全なのはない感じなんだろうか？
(ローカルホストでも絶対安全だとは言ってない)