身に覚えのない通信先とCDNについてのめも
前置き
netstatで各ポートの様子やコネクションの状態を確認していたら、見知らぬアドレスに対するハーフクローズの通信を見つけました。ずっとハーフクローズだしなんぞこれ。。。マルウェアの類だったら嫌だなぁ。。。ということでちょっと調べてみたのでメモしておきます。
また、間違っている認識や記述があれば指摘していただけると幸いです。
状態
80番ポートを使った通信をnetstatで確認したら下記のような表示になりました。
内部ホストから外部の110.232.152.33に対してCLOSE_WAITの状態を保っていました。CLOSE_WAITは、TCPの状態遷移図における状態の1つです。このホストがコネクションクローズのためのFINを受け取りACKを送ったものの、その後のFINを送信できていない状態で、これをハーフクローズと呼びます。ハーフクローズの状態があまりにも長く続いているので不審に思いました。
そして110.232.152.33とはどこぞやということで名前解決してみた結果…
回答から、deploy.akamaitechnologies.com配下のノードであることがわかりました。
通信相手についての調査結果
akamaitechnologies.comということはあのCDNを展開しているAkamaiさん…？Akamaiさんのドメインでよく知っているのはakamai.comだけど、コンテンツ配信用のドメインはそういえばなんなんだろうなぁ…などと思いつつ調べてみると、国内外問わずいろんな質問サイトに同様の質問がありました。この回答によると通信相手はやっぱりAkamaiさんのコンテンツ配信に関わるノードのようです。今回これを観測したホストはブラウジングなどクライアントとして用いていたので、その際利用したものと思われます。
AkamaiのCDNの仕組みは、オリジナルサーバを管理しているADNSのCNAMEにAkamaiのエッジサーバのドメインを登録することで、クライアントがエッジサーバ(オリジナルサーバの内容をキャッシュしたサーバ)からコンテンツを取得するようになるというものです。エッジサーバは、自身に適切なキャッシュがなければリバースプロキシとして機能し、リクエストをオリジナルサーバへ送ってキャッシュを得ます。
今回の110.232.152.33はCDNのエッジサーバってことで良いんでしょうか…？ポートスキャンをかけてみると80以外にも443が開いていました。
また、110.232.152.33についてwhoisで調べてみると以下のことがわかりました。
どうやら今回はSo-netのASにAkamaiのエッジサーバがあるっぽいですかね。実際にAS2527(So-net Entertainment Corporation)からAkamaiコンテンツが吐かれているというソースもありました*1。ここ*2でも確認しました。あれ、でもそういえばSo-netって自社でCDN持ってるんじゃなかったっけ、違ったっけ…と思いつつ調べていくと、一応、自社CDNとAkamai CDNなどによるマルチCDNといった構成を取る事業者さんもいるらしいです。その辺りも上記のJANOGにおける解説がわかりやすいです。
蛇足ですが、今まではほとんどのバックボーントラヒックはTier1を介していたのですが、それが近年では、Tier1までいかずHyperGiant(Google,Akamai)やCDNを構成するISPを介すようになった件なども上記注釈リンクにて説明されていています。トランジットへ通行料を払うよりCDNを介する方がコストも安上がりで応答性も上がったので仕方ないですね。
コネクションについて
ハーフクローズ状態がずっと続いているのが気になります。ハーフコネクションは、コネクション確立中に片方のホストが落ちた場合などに発生します。今回は、こちら側がFINを受け取った後ACKを送信してダウンしたのかな…と思ったのですが何やらホストが元気でもCLOSE＿WAITとなっている模様。もしかしたらAkamaiのエッジサーバの仕様が関わっているんでしょうか？状態が維持されたままなのはkeepaliveが変に働いているせいかとも思ったのですがwiresharkでパケットをキャプチャし続けた結果keepaliveは確認できませんでした（KeepAliveが有効なものの、KeepAliveパケット送信前に何らかの理由で接続が切れている…？）。
AWSのElastic Load Balancing(ELS)では、HTTP KeepAlive時間をLBのアイドルタイムアウト時間よりも大きい値にしなければ、LBのインスタンスへの接続を確実に閉じられない＝ハーフクローズなどが生じる可能性があります。このような形で、通信先のいずれかのノードにコネクションを正常に閉じられない問題があるのかもしれません。
ちなみに110.232.152.33とはOS起動後すぐにコネクションを確立し、さらに一定時間おきにCLOSE_WAIT,LAST_ACKでコネクションを閉じ、また3wayハンドシェイクを経てESTABLISHEDへ移行するといった状態遷移を繰り替えしている模様。
通信を行っているプロセス（原因）
継続的にパケットをキャプチャしていると以下のようなHTTP GETリクエストを投げていました（というか110.232.152.33宛のリクエストで確認できたのがこれだけでした）。
0.013133732 192.168.11.6 -> 110.232.152.33 HTTP 378 GET /cgi-bin/mgetmetar.pl?cccc=KBOS HTTP/1.1
恐らくgnomeの天気概況機能のためのリクエストだと思われるので、不審（マルウェアの類）ではないですが、gnome-pannelもAkamaiのサーバを利用しているんだなぁと… つまり、ブラウザ立ち上げなくてもAkamaiエッジサーバに定期的にコネクションを張っていたのはこいつのせいだったみたいです。OS起動後すぐにコネクション張っていたのも納得ですね。
まとめ
・見覚えの無い宛先IPアドレスはAkamaiのエッジサーバだった
・今回のAkamaiエッジサーバはSo-net（ISP）に設置されたもの
・gnome-pannelがエッジサーバに対してリクエストをなげていた
・恐らくAkamaiを利用する過程のいずれかのノードでハーフクローズの原因がある
大体通信先の謎等は解決しましたが、勝手にコネクション張ってハーフクローズで放置するアプリケーションは考えものですね…
