突然の大手Webサービスからのアクセス拒否(Access Denied)はAkamaiが原因だった―Akamai Client Reputationの影響と対処法

Tips
ServicesTips
この記事は約8分で読めます。
記事内に広告が含まれる場合があります。

先日、楽天など多数のWebサイトで、突如アクセス拒否(Access Denied)されるトラブルに遭遇しました。

トラブルの内容は、特定のWebサイト等で「Access Denied」や「You don’t have permission to access “URL” on this server.」、「Reference xxxxxx」といった文字列が表示されアクセス拒否されるというもの。

トラブルの原因は自宅のネットワーク機器等ではなく、外部サービスによるもので、具体的には「Akamai Client Reputation」の誤検出によって、Akamai CDNから弾かれていたのが原因でした。

トラブルシュートが中々厄介だったので忘備録として残しておきます。

スポンサーリンク

Akamai Client Reputationとは何か

Akamaiは、世界最大級のコンテンツ配信ネットワーク(CDN)提供事業者の1つで、同社の「Client Reputation(クライアント評価)」システムは、サイバー攻撃や不正アクセスを防ぐため、高度なアルゴリズムによってIPアドレス単位でリスクレベルを評価することで、必要に応じて評価に基づいたアクセス制限を可能にするというもの。

今回のトラブルは、このClient Reputationにおいて、自宅固定回線のIPv4アドレスがリスクありと判定されたことが原因でした。

低評価されることによる影響

Client Reputationで「低評価」IPとして判定されると、Akamai CDNを採用するWebサイトへのアクセスが(大抵)拒否される。

大抵と書いたのは、Akamaiによれば「(Client Reputationで低評価されたからといって)Akamaiが顧客Webサイトへのアクセスをブロックするわけではない」とされているため。

とはいえ、Akamai CDNにはDoS保護機能などと並んで「Client Reputationの評価を基にアクセスをブロックする」機能があり、同ブロックは多くのCDN顧客側が有効にしているため実質BANに等しい。

業界最大級というだけあってAkamaiのCDNを採用しているサービスは多く、今回のトラブルでは結構な数のサービスから締め出されました。

トラブル時に確認した限りでは、国内では楽天市場など楽天サービス全般、Softbank.jpヨドバシ.com住信SBIネット銀行などがアクセス不可に。

国外サービスでは、EA.comから弾かれてEA Appにログインできず、EAゲームのプレイが不可能になったほか、Microsoft.comにもアクセスできず。

WebサイトがAkamaiのCDNを使っているかを判別するには、(Windowsの場合)コマンドプロンプトやPowerShellなどターミナル上でnslookupコマンドによる名前解決を試し(例: nslookup www.rakuten.co.jp)、名前がakamaiedge.netなどとなっていればAkamai CDNを利用している。

nslookup www.rakuten.co.jp
サーバー:  one.one.one.one
Address:  2606:4700:4700::1111

権限のない回答:
名前:    e16791.a.akamaiedge.net
Address:  23.60.109.207
Aliases:  www.rakuten.co.jp
          evsan.rakuten.edgekey.net

なおCDNにAkamaiを使っていないWebサイトでも、「Kona Site Defender」のようなAkamai製品を利用しているとClient Reputation評価を基にアクセス拒否される場合もある模様。

低評価の原因は?

Akamaiによれば、Client ReputationではSQLインジェクションやXSS(クロスサイトスクリプティング)といったハッキング行為、DoS攻撃のようなHTTPトラフィック、Webスクレイピング、ツールによる脆弱性スキャンなどを検知した場合に、リスクありとして評価を下げるとされている。

まずは自身のPCやスマートフォン、スマートホーム関連などLAN内のデバイスが不審な動作をしていないかチェックすることをオススメ。プリンターやWi-Fiルーター等の脆弱性を突かれ乗っ取られて攻撃の踏み台にでもされていると洒落にならないので、これを機に一通りチェックすることを推奨します。

自分の例では「脆弱性スキャンツールの動作を検知したため」として低評価され、思い当たる節もなくAkamai側の誤判定という結論に。

スクレイピング動作を行うツール/スクリプトを走らせているなど該当しそうな行為があった場合、評価を回復させたければ停止するほか無さそう。またスクレイピング先のサイトがAkamai CDNを使っていても、評価ベースのブロックを行っていない場合、スクレイピングに影響は無いまま、IPは低評価されて他のAkamai利用サービスからBANされるというパターンもあるようなので注意。

評価はIPアドレス単位であるため、ルーターを再起動したらAkamai CDNからBANされたというような場合であれば、以前低評価されたIPアドレスがISPから運悪く割り振られてしまったという可能性、集合住宅などで建物全体でIPアドレスを共有している場合、同一IPの別ユーザーの低評価に巻き込まれているといった可能性もあります。

スポンサーリンク

Akamai Client Reputationにおける自身のIPアドレス評価を確認する

ということで、Akamai CDNなどを利用する特定のWebサービスにアクセスが出来ない場合、IPアドレスが低評価されている可能性があります。

Akamai Client Reputationにおける自分のIPアドレス評価値は、下記のLookupページから確認が可能で、ページを開いてreCAPTCHA通過後にGoボタンをクリックすると、アクセスしたグローバルIPアドレスの評価が表示されます。

表示結果が「The IP Address xx.xx.xx.xx did not receive a bad risk score.」であれば評価は白。

白評価の例

「Your IPv4 Address xx.xx.xx.xx received a bad risk score.」と表示された場合は、残念ながらIPv4アドレスの評価が黒。

Bad判定の場合

今回の例ではIPv4と明示されているのでIPv6アドレスが黒判定されるパターンもあるかも?

低評価判定されてしまった場合の対処法

自分の場合は心当たりもなく「(脆弱性)スキャンツールの利用を検出した」として突如Bad判定を喰らった訳ですが、Akamaiに異議申し立てを送ったところ、評価がクリーンに戻りCDNにアクセス可能となりました。

先程のLookupページの「Request to investigate your IP adress」ボタンから調査依頼……というか異議申し立てが可能(英語)。

自分の例では、「調査依頼を送る→翌日にリスク判定がクリアになるも、Akami CDNのアクセスBANは継続→翌日に再度リスク判定がBadに戻る→調査依頼(2度目)→翌日にリスク判定がクリア、CDNからのBANも解除される」という流れで解決しました。

2度目の調査依頼で「金融機関にもアクセスできず極めて迷惑なので判定基準を見直してくれ」という具合で強めに抗議したのが功を奏した?気もしますが、調査依頼で入力させられたメールアドレスに返信もなく、無言のままBAN解除されたので、誤検知だったとか何か一言くらい言えよと思わないでもない。

調査依頼を送って待っても評価が戻らない場合、「低評価されたIPアドレスを使うのをやめる」ことでアクセス制限からは逃れられるので、ルーター再起動でISPから振られるIPアドレスが更新される環境なら、ルーター再起動してしまうのが最も手っ取り早い対処法です。

IPv4アドレスが固定の場合は、辛抱強くAkamaiへ調査依頼を送り続けるしかありません……

スポンサーリンク

Akamaiも顧客企業も評価ベースでのブロックを安易に適用するのはやめるべき

今回のトラブルは、Akamaiサービスを利用している企業が多く影響が広範過ぎる割に、Web上でもあまり知られていないようで、正直一般的なネットユーザーがこのトラブルに見舞われて問題を解決できるのかといえばかなり疑問。

Akamai自身は一応Lookupページを用意するなどエンドユーザー向けの窓口を用意してはいますが、1ユーザーからすればアクセス先のWebサイトがAkamaiサービスを使っているかどうかなんてことは知ったことではない上、どこのサービスでもアクセス拒否の画面にAkamaiの文字はなく、ただアクセス拒否されたことしか分からないという不親切な表示というのが頂けない。

楽天市場に至っては、実際にはCDNへのアクセス拒否にも関わらず、まるでサーバーが混雑しているのが原因かのようなエラー表示をしてくる。これでAkamaiが原因だと気づくのは難しすぎる。

またAkamai Client Reputation評価ベースのアクセス制限を導入している顧客企業(Webサイト)側も、誤検出が原因でアクセスできないユーザーがいることを把握していないと思われ、サポートに連絡しても原因不明で解決しないでしょう。

IPアドレス単位での評価というシステム自体の是非はともかく、Akamaiには誤検知が出ないような厳格な基準で運用するなり、Webサービス提供者側も問題を把握した上でブロックを適用するなりして欲しいところです。

コメント