クラウドは今まで以上に「インターネット上の問題」を抱えるようになりました。Platform-as-a-Service（PaaS）とInfrastructure-as-a-Service（IaaS）のプロバイダなら、中小企業でもプロレベルで管理と保守が行われたサーバーインフラを展開し、想像できる限りありとあらゆるインターネットのベンチャービジネスを運用できるようできます。インターネット上で、設計的に安全ではないサービスが減少したのは、クラウドプロバイダによるものだと予想していました。単純に世界的なクラウドプロビジョニングの大手が、コンテナ化された安全設計のソフトウェアを展開できる完璧なアーキテクチャーの「シルバーシティの神話」、つまりは、天空にそびえるまばゆい銀色の都市を構築できるものと想像していました。

しかし、そうではありませんでした。実際には、クライドプロバイダは多くの場合、従来のオンプレミス環境でIT部門が苦戦しているのと同じ問題に悩まされているのでした。プロバイダが持つドキュメンテーションやデフォルト設定ですら、必ずしも安全にインターネットサービスの設定と実行を行うための近道という訳ではないのです。この結果から、インターネットの安全性が、依然としてできるだけ早く機能させて次に進みたいという要望に追いついていないという事実に気付かせられます。

Apacheのコンポーネント（ここではHTTPDのWebサーバーとJavaサーブレットランナーを指す）には、nginxなどに比べてかなり古く、多くの企業にとって可視性や管理性のない「アプライアンス」の一部となっているという明らかな欠点があります（ITとセキュリティ部門がエクスポージャーの管理を強化するためには、「ソフトウェアのBOM（部品表）」のようなものが必要になります。

グラフは全体的な分布を示していますが、これらのサービスを露出している個体数が比較的把握できていることから、業界別ランキングのアプローチは国別ランキングと若干異なります。これらの企業は十分な資金力があり、その大半が規制枠組みを遵守しなければならず、独自の情報技術および情報セキュリティの専門家を有しています。多くは創業から10年以上経過しており、対象企業の全てが基礎的なITおよびサイバー衛生を実践しています。

これらを念頭に置いたうえで、汚れやネズミの侵入のサイバー版を、各業界グループに見られた「高」（CVSS8.5以上）脆弱性の数字として定義し、ニューヨーク市がレストランの格付けを行うのと同様に、アルファベットを割り当てました。割り当てられたアルファベットは、業界ごとのエクスポージャーの高さの対数平均で決定されています（一部の業界は他よりも企業数がはるかに少なく、また業界によっては数百、数千に上るアセットのエクスポージャーに関与しているため）。結果は表3の通りです。

過去12カ月ほどを振り返ると、発生した侵入やランサムウェアのほとんどが、グレード「D」の業界に集中していることから、同業界が他業界に後れを取っていることは当然だといえます。

一方、「完璧」に近い業界はなく、サイバー衛生という点では各地域に掲載されている企業は、さらなる努力が必要であるということが前回のICERから分かりました。これは、Apache HTTPDの高エクスポージャーの80%が、3年から14年前のバージョンであるという事実からも明らかです。

それでも、悪いことばかりではありません。ICER全体で1,500社弱が所有するパブリックIPv4スペースをマッピングしたところ、重大なエクスポージャーがあったのは、611社（40％以下）と少数でした。老朽化するITアプリケーションやインフラを、最新のコンポーネントに置き換える企業が増えると同時に、この割合はさらに低下すると見込んでいます。

上記のようなインターネットエンジニアリングの観点から、さらなる努力が必要なことは明らかです。この1年間でインターネットは徐々に改善され、現代のインターネットにあふれる生物学的および経済的な危機、脆弱性、そしてエクスポージャーには耐えているように見えます。このようなエクスポージャーは、不十分な設計の古いソフトウェア、重要な「バックエンド」サービスの過剰な有用性、コントロールされていないオペレーティングシステムコンソールのアクセスポイントと定期的なパッチやアップグレードといったメンテナンスの欠如を通して、深刻なリスクをもたらし続けます。

さらに、インターネットベースの攻撃者が、このような設計、展開、アクセス、保守の欠点を十分に把握しており、すでに何の報いも受けずに、インターネット上の弱い標的を悪用していることは、私たちも分かっています。有効な「インターネット警察」がパトロールをしているわけではありません。つまり、インターネットインフラの安全性は、世界中のITおよびサイバーセキュリティの専門家、そして彼らへの技術の伝授、訓練、助言、そして金銭的援助にかかっているのです。

ある時点のエクスポージャーを見ることにも多くのメリットがありますが、Rapid7 Labsチームは、多くの変化が生じたことから、2019年4月と2020年4月の比較に非常に興味がありました。

レポートの作成では、グローバルパンデミックと差し迫る世界的不況に関して、人々が在宅勤務を余儀なくされたことで「RDPサーバーが増加する」ものの、GUIコンソールへのアクセスは引き続き必要であるとか、遠隔の労働力を組み込むために人々が慌ててWindowsのワークフローを再構成したことから、「SMBが急増する」など、いくつかの仮説を立てました。結局、私たちの予想は大きく外れました。以下の表では、2020年の調査対象となったプロトコルが、2019年の同時期のサンプル調査と比較して増減、主に減少していることが分かります。

表の説明を行う前に、少なくともコアサービスに関連した部分では、インターネットの安全性が向上しているということを喜んでお伝えします。ひねくれ者のセキュリティのプロとして、書き慣れない文章です。しかし、データは嘘をつきません。では結果を見ましょう。

まず、「変更の割合」の列で、ハイライトされていないサービスがいくつかあります。付録の「調査方法」のセクションにある通り、インターネットのスキャンには危険が伴います。私たちは過去6年にわたってあるスキャンがどのように「おかしい」かを理解するのに十分なスキャンデータを収集しました（クラウドプロバイ��のダイナミックサービスプロビジョニング増加に伴い、年々悪化しています）。Project Sonarの各調査にはそれぞれの精度範囲がありますが、全体的に+/-4％の差異がある場合、何かが「上がった」または「下がった」という絶対的な記述ができないということになります。しかしながら、ほとんどのサービスの数値は、その範囲から大きく外れていました。

Microsoft SMBは、主にISPによるSMBポートのブロックにより、エクスポージャーは20％近く減少しました。しかし、現在もSMBサービスを露出しているWindowsやLinuxシステムは50万件以上もあるので、喜ぶのはまだ早いです。

過去4年間にわたり、皆さまに使用をやめるよう訴えてきたTelnetが15％近く減少したことは喜ばしいことです。しかしまだ、残りの280万というかなりの数のルーターやスイッチといったデバイスがTelnetによって露出されています。このようなサービスが1999年の設定モードのままだからと言って、私たちまでその年に縛られるべきではないのです。

人々が自身のメールインフラをホストすることを止めているのは、喜ばしいことです。このように、Outlook 365やG Suiteなど、プロフェッショナルなメールサービスのホストへの移行は、突然の閉鎖により加速されたという可能性もありますが、メールの中央集中化はそれ以前から始まっており、今後も続くと予想しています。

SSHが13％増加したことについては、少し懸念があります（SSHサービスと、それをホストするオペレーティングシステムの脆弱性がいかに深刻かについては、SSHセクションを参照してください）。今後は、Linuxの流通がUbuntuを模倣し、安定したリモートシステムの接続には、SSHと同等またはそれ以上に安全でセキュアなWireGuardを採用することで接続性も向上し、時間の経過とともにSSHが減少することを期待しています。

最後に、DoTサーバー数が過去1年間に2倍近くに増加したことは想定していたことで、2021年にはさらに2倍（またはそれ以上）になると見込んでいます。

このように、パンデミックによるロックダウンや経済的な不透明感の中で、人々の働き方やインターネットの利用が大幅に変化したものの、インターネット自体の性質や特徴に大きなシフトは見られませんでした。結局のところ、インターネットは世界的な災害を考慮して設計されており、その点では素晴らしい仕事をしているようです。

次は、プロトコル別の分析に移ります。いつも通りの悲観的な見方に戻りましょう。

インターネットの初代ユーザーたちがコンソールアクセス得たら、次はリモートシステムとファイルを送受信する方法が必要でした。ファイル共有は、自分のデバイスにエンコードされた動画をストリームしたり、猫の写真をたくさん見たり、またはキャッシュされていないページを訪問する度に約70個のファイルがダウンロードされるウェブサイトとインタラクトしたりと、現代のインターネットトラフィックの大半を占めるものです。

現代のインターネットにおけるファイル共有の種類は、Webリソースの要求だけではありません。本レポートでは、この「ファイル共有」という広範なサービス分類で、以下の3種類のサービスについて調査しました。

• ファイル転送プロトコル（FTP）（TCP/21）と「セキュア」FTP（TCP/990）
• Server Message Block（SMB）（TCP/445）
• Rsync（TCP/873）

これらのサービスには、インターネット上のエクスポージャーという点で、それぞれ独自の安全性に関する問題があります。

まずは2種類のFTPについて説明します。

FTP (TCP/21)

分かりにくいデータチャネル交渉シーケンスと、完全なクリアテキスト。うまく行くわけがありません。

調査結果の詳細

FTP（TCP/21のバリアント）は1972年に、「シンプルかつスムーズで、容易に実装できるプロトコルデザインで、maxi-HOST、mini-HOST、Datacomputerユーザーの多様なニーズを満たす」ために開発されました。これは、クリアテキストのコマンド駆動型プロトコルで、その実用性以上に生き残っています。特に今では、ブラウザ開発の大手2社が、サポートを中止した、または中止する計画です。

Project Sonarでは、1,300万件弱（1,299万1,544）のアクティブなFTPサイトが見つかりました。前回のNational Exposure Index調査と比べ、2,000万件以上の減少となりました。FTPのインターネットへの露出では、米国が第1位で、390万件近くのホストが「OPEN」を待っています。

少し驚いたのは、FTPはクラウド環境に大きなプレゼンスがあり、Alibaba、Amazon、OVH、Azureが検出されたノードの約13.5％をホスティングしているということです。

さらに詳しく調べると、AlibabaがLinuxとWindowsの両方で「FTPサイト構築」方法を詳細にわたって説明しており、またAmazonが新しいFTPサービスを提供していることが分かりました。同様に、OVHとMicrosoftにもFTPに関する文書があり、OVHに至っては、クライアントに対して、ウェブコンテンツのファイル管理にFTPを利用することを積極的に奨励しています。

さらにすべてのプロバイダに、FTPを搭載するか、または簡単にインストールできるというベース画像（前述の役に立つ文書から）があります。そのため、クラウド環境におけるFTPエクスポージャーの高さは、当然と言えます。

エクスポージャー情報

2020年に容認できるFTPの利用方法はただ1つです。それは、どちらかというとパブリックなデータで、匿名のFTPダウンロードサービスを提供することです。クリアテキストの認証情報が露出されないのは、このような使い方だけです（それでもトランジット中のデータは露出されます）。それ以外の使用方法は、すべて不安定かつ安全でないと見なし、避けてください。FTPはネイティブのチェックサムや他のエラーチェックをファイル転送で行わないため、この方法ですら、トランジット内のデータが中間者攻撃で容易に変更されるため、危険が伴います。

それでも、インターネットには数百万というFTPサーバーがあります。私たちはいくつかのフィンガープリントを検出することができました。以下の表は、認証済みや匿名のものを含むFTPの世界を、かなり忠実に表しています。

最後の列は読み間違いではありません。166件のプリンターがFTPサービスをインターネットに露出しているのです。おそらく、より心配するべきなのは、FTPを露出しているUbiquiti UniFi Sequare Gateway（ファイアウォール）3,401件です。

FTPサーバーのうち14種類で、比較的簡単にバージョン番号のフィンガープリントが行えます。その95％を、vsFTPd、ProFTPD、Bftpd、およびFilezillaが占めています（つまり210万件のFTPサーバーが、露出されたシステムの17％近くを占めているということ）。各種類の全バージョンをまとめるのは、膨大な作業になるため、トップ5のバージョンをコメント付きでまとめました。

アドバイス

ITとITセキュリティチームは、内部および外部両方でFTP（TCP/21）の使用を避けてください。このクリアテキストプロトコルは本質的に安全性が低く、はるかに安全で優れた新しい代替手段があります。システム間ファイル転送では、FTPの「S」バージョン（FTPSまたはSFTP）や、（できれば）広いクライアントおよびサーバーサポートのあるSCPが、より安全でかつ手早い代替手段です。よりインタラクティブに使用するには、商業的に利用でき、HTTPS上で動作するオープンソースのファイル共有ソリューションも多くあります。本当にインフラコンポーネントでFTPファームウェアの更新が必要な場合は、少なくともエンドポイントがインターネットに面していないことを確認し、認証情報が除かれないように内部のVPNゲートウェイで隠すことを検討してください。

脆弱性のスキャンや、パブリックにおける攻撃面のモニタリングの際はFTPもフラグしてください。調達プロセスでは、ソリューションのサポートでFTPが含まれている、またはFTPを必要とするかを確認し、その情報に基づいて安全な製品やサービスを選ぶようにしてください。

クラウドプロバイダは、安全性が非常に低いサービスの設定に関する親しみやすい文書を提供するのではなく、FTPがインストールされていない、またはデフォルトで有効になっていないベース画像だけを提供して、FTPの使用を避けるように呼びかけてください。サービス文書やその他の指示書は、明確にFTPの使用を止めさせ、露出されたFTPが見つかった際には、ユーザーに関連する通知ができる定期的なサービスの提供をプロバイダは検討してください。可能であれば、FTPプロトコル自体、またTCP/21はデフォルトでブロックし、標準のSaaSサービスからは必ず外してください。

政府のサイバーセキュリティ機関は、代替サービスの提案とともにFTPの危険性に関するガイダンスを提供してください。エクスポージャーセクションで述べた通り、インターネットに面したFTPシステムのかなりの数で、認証されていないRCEの脆弱性が見つかっています。これは、攻撃者が選びやすい標的、そしてFTPサービスが露出されている各国の公共インフラの本質的な弱点となります。

FTP/S (TCP/990)

調査結果の詳細

FTP/S（TCP/990のバリアント）は1997年に、前のセクションで説明したFTPプロトコルに残るセキュリティ問題を解決するために開発されました。本質的には、FTPのやや安全なバージョンです。残念ながら、安全になるのはログインだけで、ファイル転送は盗難に対する保護や、トランジット内の変更が全くないまま、クリアテキストで行われます。もう1つの利点は、FTP/Sサーバーが（HTTPSサーバー同様）暗号化の確実性を持ってアイデンティティを主張できることですが、これにはクライアントが実際に証明書の詳細を確認し、証明書の識別が失敗したときに正しい対策を講じなければなりません。

FTP/Sが、安全性の低い従兄弟とほぼ同じながらも、使用する上では比較的安全であることを考えると、より広く使われていると思うかもしれませんが、そうではありません。Project Sonarでは、パブリックインターネットで普通のFTPサーバーが何百万も見つかったのに対し、FTP/Sはわずか50万ノードでした。考えられる大きな1つの理由は、FTP/Sのプロセスで、HTTPSで前ほど単純ではなくなったTLS証明の作成、インストール、定期的な更新の必要性です。

FTP/Sは米国に集中していますが（主にAzureが広く普及しているためで、これについては後に説明します）、ポーランドではhome.plのホスティングプロバイダーが従来のFTPからの切り替えに尽力しています。他のクラウドプロバイダにも是非このような文書化の努力をしていただきたいです

残念ながら、home.plは本レポートに記載されている調査で、トップ10入りするには十分なノードが露出されませんでしたが、Microsoft同様、正しいことを行っています。前述のFTP文書に加え、彼らには専用のFTP/S設定と指示書があり、「エクスポージャー」セクションの表から察することができる通り、IISでFTP/Sを有効化するのが非常に簡単です。

このような努力があっても、ユーザーはおそらくFTP/SではなくSCPを使用していると思われます。SCPはトランジット内のファイルコンテンツだけでなく、ログイン認証情報も暗号化するからです。

エクスポージャー情報

Recogがフィンガープリントできた利用可能なFTP/Sサービスは、わずか8万4,697件（18％でした）が、FTP/Sで利用できる明示的な設定パラメータがあり、証明書の要求とインストールにはGUIが備わっているため、今回はIISの「勝ち」となりました。

多くのFTP/SサーバーがFTPとFTP/Sサーバーの機能を備えているため、同じ脆弱性が適用されます。IISについては、本レポートの「Webサーバー」セクションで詳しく説明します。

アドバイス

ITとITセキュリティチームは、内容がほぼ同じであるため、FTPセクションのアドバイスに沿ってください。いつも事前に暗号化されたファイルを送信している、またはアップロードやダウンロードするコンテンツが機密情報でない（または中間者に覗かれたり変更されたりすることが気にならない）のであれば、もう少しの間FTP/Sの使用を続けられるかもしれません。

クラウドプロバイダは、home.plの例に倣い、安全なファイル転送に関するFTP/Sの可能性や限界を明確に説明してください。FTP/Sに依存しているシステムがあったとしても、クラウドプロバイダはSSH上のSCPやrsyncなど、総合的なソリューションを積極的に推進する必要があります。

政府のサイバーセキュリティ機関は、安全なファイル転送に関するFTP/Sの可能性や限界を明確に説明し、代替サービスを提案してください。「FTPエクスポージャー」のセクション（FTP/Sにも適用）で述べているように、比較的少ない、インターネットに面するFTP/Sシステムにも、認証されていないRCEの脆弱性が存在しており、攻撃者が選びやすい標的、そしてFTPサービスが露出されている各国の公共インフラの本質的な弱点となります。

SMB (TCP/445)

こだわる攻撃者はSMBを狙います。

調査結果の詳細

SMBは、世界中のネットワークオペレータにとって、今でも頭痛の種です。元々、NetBEUIやIPX/SPXなどのローカルエリアネットワークプロトコルで動作するように設計されたSMBv1は、他のインターネットが動作する通常のTCP/IPネットワークに移植されました。それ以降、SMBv2とSMBv3がリリースされています。SMBは主に、認証、ファイル共有、印刷サービス、プロセスコントロールなどでWindowsベースのコンピュータに関連付けられますが、同時にSambaやNetsmbなど、Windows以外のオペレーティングシステムの実装でも使われています。交渉可能な暗号化機能があるバイナリプロトコルとしては、複雑なプロトコルです。この複雑性、また初期の独特な性質やオペレーティングシステムカーネルとの深い結びつきから、リモートコード実行（RCE）を可能にするセキュリティの脆弱性をkするのに最適です。これに加えて、デスクトップオペレーティングシステムとしてのWindowsが世界的に人気であることから、バグハンターやエクスプロイターにも人気のターゲットであり続けます。

エクスポージャー情報

最も良く知られている脆弱性、エクスプロイト、および野放しのワームが、何らかの形でSMBを活用しています。WannaCryとNotPetyaは、SMBが悪用と感染の中心となった、最も新しいイベントの2つです。過去に発生したSMBベースの攻撃には、NachiおよびBlasterワーム（2003年～2005年）があり、今後のSMBベースの攻撃では、SMBGhostが含まれると見られています。バグに加え、SMBの意図的な機能（特に自動パスワードハッシュ）が、無防備な被害者からパスワードのハッシュを盗むのに理想的なメカニズムとなります。また、SMBシェア（ネットワークに露出されているファイルのディレクトリ）は、サーバーの不十分な管理や、使いやす過ぎるネットワークアタッチストレージ（NAS）を通し、引き続き事故的にインターネットに露出され続けています。

利用可能なSMBサービスのほとんどがWindowsベースであることは予想通りですが、以下の表からは、少数派であるWindows以外のSMBもある程度見られます。

ご覧のとおり、これらのWindows以外のノードは通常、主にWindows環境で使用されているNASシステムの一種であり、ニアラインバックアップシステムの維持を行うものです。これらがWindowsシステムを攻撃するものと同じエクスプロイトに対して脆弱である可能性は低いものの、このようなバックアップがインターネットに露出されているというだけでも、次にランサムウェアの波が襲ってきたら、これらのネットワークオペレータは非常に苦労することになります。

自動インストール

インターネットに露出されているWindowsマシンから、Sonarスキャンに見られるワークグループストリングの原点について、少し学ぶことができます。以下のリストは、これらのマシンのほとんどが、デフォルトの「WORKGROUP」というワークグループを使用しており、その他は標準の自動インストールで自動生成されたものです。SMBがとても珍しいもので、インターネットに露出するのが安全だったまるで魔法のような世界では、これらのマシンは手動で設定され、定期的にパッチが当てられていると思われていたかもしれません。

しかし実際にはそんなことはありえません。これらのWindowsオペレーティングシステムは、おそらく自動的にインストールおよび設定され、インターネットへの露出については特に気にされることもありませんでした。そのため、エクスポージャーはほぼ間違いなく偶然の産物で、特別な、非常に重要なビジネス機能を果たしていないことになります。さらに、アフターマーケットでデフォルトとなっているWORKGROUPが、WindowsまたはSambaベースのビルドがプロダクション環境で使われているというヒントを与えてしまい、攻撃者にこれらのシステムを狙わせてしまうことになります。

攻撃者の視点

暗号化やその他のセキュリティコントロールのバージョンや設定に関係なく、SMBは今日のインターネットには不適切です。確実に安全にするには複雑過ぎていて、また犯罪に悪用しやすい重大な脆弱性が、プロトコルに現れ続けているからです。それでも、SMBは今でもあらゆる規模のオフィス環境で重要なネットワークレイヤーであり、TCP/IPにネイティブであるため、ネットワークの誤設定でSMBベースのリソースを直接インターネットに露出してしまうことも考えられます。すべての組織はネットワークのイングレスおよびイーグレスフィルタを継続的に点検し、部外者がSMBトラフィックを誤って露出されたリソースに送信することを防ぐだけでなく、内部のユーザーが、過失によりSMB認証トラフィックを外部に漏洩させないようにする必要があります。

調査期間中、約64万件のIPアドレスが、ハイ・インタラクション型SMBハニーポットを訪れましたが、これをSMB犯罪者の大群として考えるのではなく、これらの接続の大半は、インターネット上にある無人のマシンからであるということを覚えておいてください。侵入済み。結局のところ、それがワームのやり方です。このような接続のうち、（pwnedではなく）攻撃者が個人的に所有するマシンがソースであると考えられるのは、ごくわずかです。これを念頭に置いたうえで、私たちのハニーポットトラフィックから、現在どの国がWannacryのようなSMBベースのメガワームに露出されているかが大体分かります。リストの上位国は、ベトナム、ロシア、インドネシア、ブラジル、そしてインドでした。

クラウドプロバイダ間では、状況はさらに顕著です。Digital Oceanから私たちのハニーポットへの接続の約150万件が、WannaCryを支えているエクスプロイトのエターナルブルーによるものでした。一方、Microsoft Azureがソースとなっていた（エターナルブルーではない）接続は、約800万件でした（そのうちの約12％にあたる120万件ほどが、Azureでの設定ミスによる偶然の接続でした）。Digital OceanとAzureの攻撃トラフィックと偶然のトラフィックの間に、なぜこれほど大きな相違があるのかはまだ分かっていません。しかし、MicrosoftがAzureのデフォルトオファリングが、MSS17-010に沿ってパッチされていることを厳しく徹底している一方で、Digital Oceanはパッチの徹底をそこまでしておらず、ユーザーベースに定期的なメンテナンスを任せているということが理由として考えられます。

アドバイス

ITとITセキュリティチームは、VPN接続されたネットワーク以外の組織とのSMBアクセスを双方向で禁じ、また外部に面した既知のIPアドレススペースで、設定ミスのあるSMBサーバーがないかを定期的にスキャンしてください。

クラウドプロバイダは、クラウドリソースへのSMBアクセスを禁じ、少なくともSMBアクセスの外部リソースへのアクセスを定期的に調べてください。ハニーポットへのSMBを通した、Microsoft Azureからのインバウンド接続のうち約15％が攻撃やプローブではなく、実は設定ミスであることを考えると、Azureは特にこの一般的な欠陥を認識し、現在見られるレベルにまでSMBを偶然露出するのを不可能にするべきです。

政府のサイバーセキュリティ機関は、自国のSMBへのエクスポージャーを正確に把握し、定期的なスキャンや、SMBアクセスが検出された際にはそれをシャットダウンする通知プログラムを確立してください。これは特に、ハニーポットソースリストの上位国に当てはまることです。

rsync (873)

初期のインターネットエンジニアリングの事故ともいえます。

調査結果の詳細

rsyncサービスは誕生から24年経ち、人間でいえば米国でレンタカーを借りれるほどの年になりました。多くのネットワークプロトコルとは異なり、rsyncはプロトコル自体にはIETF RFCはありませんが、Uniform Resource Identifier（URIですが、URLだと考えても結構です）が知られるようになり、この尊いプロトコルは少なくともURIスキームで部分的なRFCステータスを獲得しました。rsyncにはドキュメンテーションがあり、最新のインターネット上で広く使われており、ソフトウェアとオペレーティングシステムミラーやファイルシステムを人々に活用させ、バックアップを実行することで（後に説明します）、かなりの数のホームネットワークアタッチストレージ（NAS）を露出させています。

Rapid7のJon HartとShan Sikdarは、2018年にrsyncのエクスポージャーについて詳しく調査しましたが、それから現在までにはわずかな変化しか見られません。そのため、重複する調査は行わず、その変化にのみ注目します。

なぜ中国のAlibabaとフランスのOVHが他のプロバイダに比べて大きなrsyncのプレゼンスを持っているのかと疑問に思っている方は、「クラウド」に馴染みのない人々がジャンプスタートする際に頼りとする、それらのドキュメント[1]やサービス[2]を見れば分かります。残念ながら、両方のクラウドがデフォルトで平凡なrsyncを使用していますが、少なくとも、SSHトンネルを通して実行の安全性を高められるということに言及しています。

エクスポージャー情報

露出されたrsyncシステムの半分以上（約57％）が、10年前のプロトコル（バージョン30）で実行されており、オペレーティングシステムが10年以上も同じままで、他の脆弱性に悩まされているということが分かります。プロトコルのバージョン31が最新のものですが、これは少し誤解を招く可能性もあります。バージョン31は、2013年にリリースされました。プロトコルのバージョン30と31以外では、本当に古いバージョンが急激に減少しています。

rsyncエクスポージャーの20％以上が家庭向けISPスペース（トップ25は以下のリストに記載）にあることから、これまでのセクションとは少し方向を変える必要があります。これらのほとんどは、オンラインストアや大箱の家電量販店で見たことのあるブランドのNASデバイスです。これがなぜ重要なのかについては、次のセクションで説明します。

コアのrsyncサービスには暗号化がないため、認証を含むすべての操作は、クリアテキスト上で行われます。つまり、TelnetやFTPと同じくらい危険ということです。このプロトコルは、非クリアテキスト認証の使用をサポートするために拡張されていますが、ファイル転送はいまだにクリアテキストで行われるため、正しいネットワークポジションを覗けば、データを盗むことが可能です。

しかし、rsyncを露出させることが本当に危険である理由の1つは、攻撃者に対して盗めるファイルや、乗っ取る価値があるかも知れないオペレーティングシステムがあることを知らせてしまうということです。

攻撃者の視点

rsyncは「ファイルあります！」という大きなネオンサインで、また露出されたrsyncの大部分が家庭用ISPネットワークにあることから、攻撃者はそのようなIPアドレスにある他のサービスとの関連性を探り、露出されているシステムの種類を把握できます。

なぜこのような家庭用rsyncシステムがインターネット上にあるのでしょうか。QNAPなどのベンダーは、このようなNASデバイスを使いやすくするために、「myQNAPcloud」のようなサービスを作ります。これにより、ユーザーは「nameyouwant.myqnapcloud.com」を作成して、インターネット上で自分のデバイスにアクセスできるようになります（これを行うには、自宅のルーターに少なくとも1つの穴を開けなければいけません）。また、保存した動画や音楽を視聴できる便利なモバイルアプリもあります。Sonar FDNS調査では、12万5,000件以上のmyqnapcloud.comエントリが見つかりました。攻撃者がデータを収集するのは非常に簡単なことです。つまり、12万5,000件以上のQNAP NASユーザーが、攻撃者に自宅の（IP）アドレスを渡して、昔ながらの「Welcome」と書かれたマットを入り口に敷いいているようなものです。

残念ながら、QNAP（および他のNASベンダー）は、7つの認証されていないリモートコード実行に関連するもの（中でも最新のものがひどい）を含む脆弱性については、これまで十分な対策を講じていませんでした。これらの脆弱性はrsync上で露出されてはいないものの、前述の通り、NASデバイスがある可能性が高いことを示す大きな目印になります。

攻撃者はこのようなデバイスを、インターネット上の他の悪意のあるアクティビティ（DDoS攻撃など）の開始ポイントとして使用し、これらのデバイス上のすべてのファイルをロックして、一般消費者向けにランサムウェア攻撃を行うこともあります。

ご覧のとおり、rsyncといった1つの純粋なサービスを露出することで、大きなトラブルを引き起こす可能性があるのです。

Heisenbergのハニーポット隊には、rsyncのハイ・インタラクションハニーポットはありませんが、TC/873への接続試行はすべて見つけ、侵攻する新たなrsyncのエンドポイントを探しているリサーチャーや攻撃者の定期的なインベントリスキャンを観察しました。

アドバイス

ITとITセキュリティチームは、決して従来のrsyncを使用せず、常にそれを甘いチョコレートのような安全なシェルに包んでください（つまり、証明書ベースの認証されたSSHセッションをトンネリングする場合にのみ使用してください）。機密情報にrsyncを使用するのに、他に安全な方法はありません。なし

クラウドプロバイダは、証明書ベースの認証済みのSSH以外のrsyncサービス以外は提供しないでください。既存の安全性が低いサービスは、できるだけ速やかにフェーズアウトしてください。このような、どこにいても暗号化するという世界に近づくうえで、最も分かりやすいな道は、rsync-over-SSHを始める方法が例とともに示された、十分に保守されていて見つけやすいドキュメントを提供することです。反対に、rsyncを裸で実行する方法についてのドキュメントは最低限に留めるか、または全く必要ありません（過ちをどうしても犯したいというユーザーは、昔のように頑張ってマニュアルを読めば良いのです）。

政府のサイバーセキュリティ機関は、消費者、クラウドプロバイダ、そして組織に対し、証明書ベースの認証されたSSHトンネルを通したrsyncサービスの使用を定期的に、かつ強く奨励してください。また、クラウドプロバイダやNASベンダーと協力し、そのようなプラットフォームからのrsyncエクスポージャー被害を根絶してください。

ここで、はっきりと伝えなければならないことがあります。コンソール端末のセッションで説明した内容は多くのタスクにとって役に立ちません。皆さんと同様に、私たちもコマンドラインのファンですが、最新のITエコシステムでは、リモートデスクトップやサーバー環境のグラフィカルユーザーインターフェース（GUI）の方が有効です。従来の（つまり、ブラウザベースでない）デスクトップアプリケーションにリモートアクセスを与えるにしても、イントラネットリソースへのアクセスを防ぐにしても、さらに完全なデスクトップのインタラクティブセッションの遠隔利用を有効にするにしても、これらのソリューションが真のニーズを満たし、Get Stuff Done™のような組織作りに役立ちます。

この現実を認識したうえで、非常に人気の高い2つのリモートアクセスサービスについて見てみました。

• Virtual Network Computing（VNC、TCP/5900）
• Microsoft Remote Desktop（RDP、TCP/3389）

拝啓、X-Window様、大変申し訳ありません、貴君の時代は終わりました。今後は、天文学研究室とハリウッド映画のハッキングシーンでご活躍ください。

VNC (5900 & 5901)

これはRFBですが、どういう訳か誰もそうは呼びません。

調査結果の詳細

Project Sonarは、5,900件ンのデフォルトポートと人気のある代替ポートで、34万7,940件のVNCサーバーを見つけました。その他のソースで、さらに大きな数字を見たことがあるという場合（具体的には、素晴らしい調査結果であるKasperskyのサマリーペーパーをご覧ください）、VNCはインターネットの未開拓地にある多くのポートにも存在しているため、そのような数字もおそらく正確なものです。理由はどうであれ、VNC実装は、設計上の決定として、IANAが割り当てたポート番号を厳密に遵守しません。つまり、エクスポージャーのベースラインとして私たちの数字を使うことはできます。一方、少なくとも60％近くのVNCユーザーがサービスで最も一般的なポートを使うという結果が出ていますが、国やネットワーク別の分布を一般化し過ぎるのは避けた方が良いでしょう

ここでは、OVHがリードしています。これは、「VNCを通してパブリッククラウドインスタンスにアクセスする方法」に関する「役立つ」サポートページがあるためです。VCNにはルートユーザーとしてログインするため、このページにはルートユーザー用のパスワードの設定方法も記載されています。これは多くの規制基準に違反しており、本当に泣きたくなります。

AmazonもAlibabaやDigitalOceanに並び、わざわざ攻撃面を広げる手助けをしています。これで、クラウドエクスポージャービューで彼らが「トップ4」となった理由がお分かりになるでしょう。

エクスポージャー情報

本レポートのいくつかのセクションでもそうだったように、VNCにおけるビジネスおよび家庭用ISPのエクスポージャーについて話す必要があります。なぜなら、これが全てのエクスポージャーのうち大きな割合を占めているからです。以下のISP/プロバイダは、発見されたVNCノードの合計30％を占めました。

すでにお聞きになったことがあるかも知れませんが、これらのノードは主に、内部ネットワークの何かに、迅速なリモートアクセスを必要とする企業か、または遠隔で自宅システムにアクセスしたい、家庭ユーザーです。

認証情報を推測しようとするのは、どのような方法であっても米国ではCFAAの違反になります。調査チームはオレンジ色の囚人服を着たくはないので、ログインが必要なシステムの数を調べることはできません。また、画像に機密情報が含まれていた場合、多くの地域でプライバシー法の違反となるため、スクリーンショットを撮ることもできません。

発見されたサーバーの52％がRFBのバージョン3.8（最も新しいRFBのスタンダード）を使用しており、次に多かったのは何らかのmacOSを使用しているというのが19％でした。これは、Apple製のコンピュータが、ある程度の数字で現れる可能性が高い、数少ないプロトコルの1つです。VNC上では、adminインターフェースを露出している数十台のマルチファンクションデバイスも見つかりました。

攻撃者の視点

数年間にわたり、VNCの全バージョンで多くのバグが見つかっていますが、幸い、そのほとんどは認証済みのセッションがなければ効果が出ません。しかしながら、「ダークウェブ」にはただ試行されるのを待っている80億以上の認証情報が出回っています。

他のサービス同様、HeisenbergハニーポットネットワークではVNCサービスを取り上げていません。そのため、上記のグラフに示されているのは、日和見主義的なスキャンまたは組織の設定ミス（AWS、GoogleまたはRackspaceで、あると思っていたIPアドレスにない、かつて所有していたVNCサーバーを狙うなど）です。

接続の試行回数が多いことから、VNCをインターネットに露出する際は十分に注意して、一度も使用されたことのない強力な認証情報でパッチが当てられていないVNCサーバーコードを使用し、さらに多要素認証で安全性を強化してください。

アドバイス

ITとITセキュリティチームは、すべてのVNCアクセスをVPN接続やSSHトンネルの背後に置き、絶対にVNCを直接インターネットに露出させないようにしてください。VNCアクセスのあるホストをパブリックインターネットで使用するには、設定や維持で気を付けるべきことが多くあります。

クラウドプロバイダは、VNCを裸のまま使用することは避けるように呼びかけ、VNC-over-SSHなど、より安全でコツと効率の高いソリューションをユーザーに提案してください。当然ながら、セキュリティが強化されたVNCのクライアントやサーバーのセットアップはありますが、チュートリアルやセットアップガイドの多くは、ユーザーの攻撃面を広げるだけのものです。

政府のサイバーセキュリティ機関は、VNCの安全な使用方法のガイダンスを定期的に公開し、VNCの脆弱性開示を監視し、また時宜を得たアラートを発行して、インターネットサービスプロバイダに少なくともデフォルトポート（5900）ではVNCアクセスをブロックするよう奨励してください。

リモートデスクトップ — RDP (3389)

これはVNCに似ていますが、マイクロソフト寄りのものです。

WindowsXP（2001）の導入により、さまざまなイノベーションが生まれました。例として、マルウェアの広範におよぶ分布、ブルースクリーンによるデータ損失、さらには、リモートデスクトップ接続を介して他のWindowsXPシステムのキーボードビデオマウス（KVM）接続が容易に可能となるという新たな機能などです（以前は「端末サービス」と呼ばれていましたが、Microsoftはその名前が気に入らなかったようです）。これはXP以降すべてのWindowsバージョンに搭載されており、ほとんどのユーザーが遠隔でWindowsシステムにアクセスする際、主にこの方法を使っています。サイバーセキュリティ関係者の多くは、Microsoft Remote Desktopについて話す時は、 RDP（リモートデスクトッププロトコル）のショートカットを使用します。

調査結果の詳細

Project Sonarは、400万件弱の活発なRDPノードを発見しました。そのうちの4分の1以上が中国に帰属するネットワークです。

エクスポージャー情報

当然のことながら、RDPノードの約4分の1が、調査対象のクラウドプロバイダネットワーク内にありました。Microsoft Azureがトップになると予想していましたが（Windowsですから）、結局のところ、接続しなくてもこのようなリモートシステムは利用できるという訳です。ですから、AzureがホストするRDPが3位だったことを知ったときは、驚きました。3位と言っても、クラウドの巨人であるAmazonとAlibabaに次いでいるので、これは強力な3位です。

RDPはどこにでもあり、その数は（VNCの40万弱に対し、400万以上で）VNCを一桁上回っています。前述の「クラウド」使用の場合以外では、中小企業がビジネスクラスのISP接続で、または事業がリモートアクセスや管理に、さらに小売り業者が日常的な管理業務でポイントオブセールスのRDPを有効にするなどの使用方法があります。またホームユーザーの間でも、家庭用PCへのリモートアクセスを有効化する上で、ファイヤーウォールに時間をかけて穴をあけるため使いやすいとされています。このような遍在性が、設定ミスのまん延や脆弱性と重なり、攻撃者にとって理想的な標的となるのです。これについては次のセクションで説明します。

RDPセッションにはさまざまな設定方法があります。Project Sonarは、「標準」または「レガシー」、「ネットワークレベル認証」（NLA）、そして「トランスポート層セ���ュリティ」（TLS）の3つのステートを認識できます。「標準」というのはあたかも列車事故の発生待っている状態で、（定期的にパッチを当て、多要素認証のある安全な設定を利用しているという前提で）NLAとTLSはどちらも、セッションの安全性を確保するのに非常に役立ちます。また、トップ10の国におけるノード比率の高さと、より安全な接続オプションがクラウドに使用さていることから、ほとんどの家庭およびビジネスクラスユーザーが、それを理解したように見えます。

一方、クラウドの仕組みはそれぞれ異なり、安全なセキュリティモードの使用という点では、Oracleクラウドのユーザーが最下位となっています（これもクラウド内のノード比率から見て判断）。これは、おそらくRDPを有効化する際のデフォルト設定が原因だと思われます。

攻撃者の視点

このプロトコルは、ハニーポットがしっかりとカバーしており、RDPセッションの確立とBlueKeep経由でのRDP悪用の試みという2つの領域に注目します。

2019年の春にMcrosoftが発表した、RDPにおける認証されていないリモートコード実行の欠陥であるBlueKeepは、かなり悲観視されていたものの、ほぼ終息しました。これは、人々が実際にパッチを当て、NLAに切り替えたためだと考えられます（国およびクラウド別の調査結果にも表れており、また調査対象となったRDPの92％がNLAを使用していたことも分かっています）。BlueKeepが当時言われていたほどの悪夢にならずに済んだのは、すべてのレベルで早期に行われた、一貫した正しい警告のおかげだったと私たちは考えています。

BlueKeepの活動の証拠がないという訳ではありません。しかし、BlueKeepの使用よりも、クレデンシャルスタッフィングの試行の方がはるかに多く見られています。

上記の図から学べることが4つあります。

• BlueKeepの数が非常に少ないということ。
• 悪意のあるユニークなソースホストの数が少ないということ。
• RDPの活動が不変であるということ。
• 攻撃者は、2020年のパンデミックにより米国がロックダウンを始めた頃、幸運が訪れるかもしれないと考えていました。

2020年1月1日から2020年4月30日までの間に、HeisenbergはBlueKeepベースのエクスプロイトの使用を試みた、またはハニーポットネットワークに対してクレデンシャルスタッフィングを行った、個別ソースのIPアドレスを8,500件以上見つけました。これらのユニークなIPv4アドレスの11％がDigitalOceanに由来していますが、悪意のあるRDPトラフィックすべてのうち16％が、オランダのホスティングプロバイダであるHostkeyから来ています。これら2つのネットワークソースが目立つ一方、1,310件の個別の自律システム（ASes）が悪意のあるソースをホストしているため、非難を目を向ける場所は多くあります。

アドバイス

ITとITセキュリティチームは、GUIリモートアクセスのためにどうしてもRDPの使用するという場合は、RDPをVPNに置くことを検討してください。RDPを直接インターネット上に置く必要がある場合は、必要に応じて行うようにし、RDPが露出されている全てのシステムにパッチが適用されており、多要素認証によってRDPの設定ができるだけ強力であることを徹底してください。

クラウドプロバイダは、かなり安全なデフォルトを確保し、弱い設定でRDPを展開したユーザーに対し、定期的な注意喚起を行ってください。ユーザーが一定期間だけ簡単にRDPを有効化できるようにすることは、クレデンシャルスタッフィング攻撃の予防に大きく役立ちます。インターネットを少しでも安全にするため、プロバイダは悪意のあるトラフィックを監視し、地域のCERTと協力して、可及的速やかに悪意のあるノードをシャットダウンさせてください。

政府のサイバーセキュリティ機関は、引き続きRDPの危険性と、安全な使い方の徹底について、人々への啓蒙活動を続けてください。悪意があるとしてよく知られるソースがあることから、セキュリティ機関は地域のCERTやホスティング/クラウドプロバイダと連携し、悪いトラフィックをリモートホストに侵入する前に止められるようにしてください。

Citrix ADC/NetScaler (TCP/Various)

これはVNCと似ていますが、例えて言うなら、Plan9がベル研究所から抜け出して、人気者になったようなものです。

Citrixは1989年に設立され、長年にわたって多様なリモートアクセスソリューションを開発してきました。最新のCitrix ADC（アプリケーション配信コントローラ）とNetScalerソリューションは、Microsoft Remote Desktop Servicesインフラを使用して、仮想アプリケーションやデスクトップをリモートユーザーに配信します。組織には、単なるなリモートデスクトップよりも堅牢なアクセスコントロールを設定することが可能で、Citrixのアプリケーション配信プロセス内では、それをさらに高速化させ、Remote Desktopセッションよりも消費する帯域幅を少なくする最適化が可能です。

調査結果の詳細

HTTPとNTPサーバーがCitrixシステムであることを通知するようになっているため、インターネット上で当該システムを認識するのは想像以上に簡単です。これにより、Rapid7 Labsのリサーチャーが、インターネット上のCitrixシステムの普及を追跡することは容易でした。また、2020年3月にはダウンロード可能なCitrixクライアントのバージョンフィンガープリントに基づいて、サーバーのバージョンフィンガープリントを見つける方法を開発しました（もう一度いいますが、Citrixが自社のシステムを認識可能しています）。

Labsチームが時間をかけてこのような取り組みを行ったのは、攻撃者が危険なリモートコード実行の脆弱性にパッチを当てていないシステムを攻撃し続けていて、私たちはさまざまな技術のパッチ適用率をモデルする多くのプロジェクトを進めているからです。

トップ10にある他の多くの国と異なり、中国はCitrixシステムのインターネットへの露出で、スウェーデンすら破れませんでした。

私たちのバージョンフィンガープリント技術では、インターネットに面するCitrixシステムの73％にパッチが当てられている、または緩和策が整っていることが分かりました。残りの27％は、脆弱、またはひどく時代遅れである（それにより他にも問題を抱えている）という状況です。パッチ率を73％まで引き上げるには、5か月かかりました。

攻撃者の視点

Heisenbergハニーポットノードの大半はクラウド環境にあり、これまでに見たように、それは通常、Citrixの居場所ではありません（少なくともパブリックインターネットのクラウドセグメントでは）。1月に、悪用できるシステムを頻繁に探している攻撃者やリサーチャーを捕まえましたが、そのアクティビティは（完全に止まってはいないものの）下火になりました。

私たちのハニーポットはCitrixをエミュレートしないため、アクティビティの不足は攻撃者のインベントリスキャン後、ノードが無視されているためだと考えられます。攻撃者はまた、初期のインベントリリストを使っているか、すでにパッチ処理に長時間かかった、数千というシステムに足掛かりを持っているのかも知れません。

アドバイス

ITとITセキュリティチームは、ベンダーからの通知やCVEレポートをくまなく監視し、可及的速やかにCitrix環境にパッチを適用してください。過去18カ月間では、リモートアクセス技術を標的にする攻撃が増えていることから、これらのシステムで、より詳細なログイン設定でモニタリングを強化するのも良いアイデアです。

Citrixはクラウド環境向けのソリューションも提供していますが、その使用はあまり普及していないようなので、クラウドプロバイダは現状の対策を引き続き行うだけで十分です。

政府のサイバーセキュリティ機関はこれまで通り、Citrixのようなリモートアクセス技術における脅威アクターの活動や、脆弱性の深刻さに関する意識向上の取り組みを続けてください。

道路、橋、信号、地図がなく、そして行き方を訪ねたり教えられたりする能力がなければ、ほとんどの国で路頭に迷うことでしょう。インターネットについても同じことが言えます。私たちは、インターネットが可能にしたアプリに依存して、サイトAからサイトBへと移動していますが、その多くのサービスを「見えないもの」として扱います。そのようなサービスの中で重要なものを取り上げ、どのように利用されていて、どれほど安全で、それぞれにどのような特性があるのかを見てみましょう。

ドメインネームシステム（DNS）（UDP/53）

「インターネットの弁慶の泣き所」- ティム・バーナーズ=リー

ネットワークリソースにアクセスするためにIPアドレスを暗記したいという人はいません。また、IPアドレスマッピングに膨大なスタンドアロンリストを持ちたい人もいません。しかし、例えば「example.com」というIPアドレスへのリクエストの応答を永遠に待てる人もいません。そこかれ生まれたのが、最も遍在的であり、ユーザーに面していながらユーザーに最も見過ごされる、インターネット上のサービスが、ドメインネームシステム（DNS）です。

調査結果の詳細

Project Sonarは、53番ポートのUDPリクエストを通じ、約500万件のDNSサーバーを発見しました。これは、例えばWebサーバーの合計数と比べればはるかに少ない数ですが、それでもシステムの数としては相当で、それには納得できる理由があります。ISPは家庭や中小企業のユーザーにDNSサービスを提供し、企業はブランドの名前空間をコントロールするために独自のDNSをホストします。またベンダーは、アウトソーシングの一環として、またはマルウェアやその他のコンテンツタイプのフィルタリングなどの高度なサービスとして、カスタマイズされたDNSサービスを提供します。最後に、Google、Cloudflare、IBM（Quad9経由）などの大手テクノロジー企業が、多くの正当な（？）理由から、集中型のDNSサービスを提供しています。 つまり、巨大な集中型DNSプロバイダを除き、世界のDNSフットプリントは割り当てられた国のIPv4を詳しく追及するということです。ある国に割り当てられたIPが多ければ多いほど、それらすべてを追跡するDNSサーバーの数も増えます。

一方、貴重（かつコストの高い）クラウドリソースを、DNSのホスティングに費やすというのは、理にかなっていません。しかしながら、OVHユーザーには、使用できるサイクル（および資金）が多くあるようです。つまり、これらは単なるOVHのDNSサーバーではありません。DNSベンダーのソフトウェアが持つ多様性とバージョンの分布から、そのような結論に達しました。現在、OVHは世界最大のデータセンターを持っており、もはや単なるクラウドサービスプロバイダではありません。そのため、同社がトップの座にあり、そうあるべきだというのは納得できます。

最も小規模な組織がISPの外部DNSを（直接または再帰的なDNSを通して）使用していること、また、ホームユーザーのほとんどがいまだ���ISPのDNSを使用していることから、自律システムのDNSサーバーの分布には大きなロングテールがあることが想像できます。

エクスポージャー情報

DNSには、これまで多くの課題がありました。DNSはリサーチャーと攻撃者の両者から、大きく注目されているバイナリプロトコルです。これと、UDPサービスの性質から、約60バイトになるバイナリDNSリクエストを作成することが可能です。このリクエストはDNSレスポンスを求め、レスポンスは4,000バイト近く（約1対7の増幅）になる可能性がるため、低～中程度の増幅型DDoS攻撃に非常に有用となります。また、年々難しくなってはいますが、特別に作成したバイナリメッセージを通じてDNSサーバーに侵入することも可能です。

BIND（現在はISC BIND）は最初のDNSサーバーで、現在でも最も普及しており（Recogフィンガープリントが見つかったものの中で）、おそらくそのために、119件のCVE（ほとんどがDoS関連）があったと考えられます。 しかし、現実はこれほど明確ではありません。ISC BINDだけでも、550件の異なるバージョンストリング（ほとんどが正当）が見つかりました。状況がどれほど混乱しているかを把握するために、DNSサーバーを持つ自律システム全体で、ベンダーごとにバージョンの多様性を見ることができます。

これが真面目な調査レポートではなくてソーシャルメディアサービスだったとしたら、今頃「それでも使っているの？」というmeme gifに「パッチ」という単語を入れて投稿しているでしょう。 つまり、私たちは使っているときにDNSのことを忘れるだけでなく、それを実行するときですら忘れてしまうということです。Denial-of-Serviceの欠陥は、これらのサーバーで毎年見られますが、DNSが実行されていたら、それは実行されているのだから、そのまま実行させておく必要があるのです。

攻撃者の視点

私たちはDDoS保護サービス市場にいるわけではなく、またDDoS攻撃の発生を検知できるよう、主要ロケーションにDDoSプローブを置いているわけでもありません。Heisenbergでは、TCPおよびUDPベースのDNSトラフィックが見られますが、そのほとんどはインベントリスキャンや設定ミスです。

これは、攻撃者がDNSのことを気にしなくなったということではありません。全てのDDoSミティゲーションベンダーは、サービスレポートで年に数回、このことを必ず私たちにリマインドしています。2019年には、VerizonがDoS全般の大幅な増加を指摘しました（これにはDNSが関連していました）。また、常に新しく巧妙な攻撃ベクトルがリサーチおよび開発されています。

しかし、DNSへの攻撃はDoSだけではありません。私たちが家から何でも購入できるようにするには、組織は、パブリックのトップレベルドメイン名を登録し、さまざまな種類の記録を設定する必要があります。これが、攻撃に2つの手段を与えます。まずはレジストラレベルで、これが多要素認証（この場合SMSではなくアプリベースが理想）でドメイン登録アカウントを保護することが必須な理由です。そして次に、外部のDNSプロバイダでも同じことをしてください（外部のDNSを利用している場合）。2020年5月に、Internet Systems Consortiumはまさにこのトピックについて、背景をより詳しく知るのに役立つウェビナーを開催しました。また、SpamHausは、GoDaddyでは毎日約100件のドメインが新たにハイジャックされていると推定しています。

DNSをコントロールする者が、インターネット上でのあなたの身分を決めるのです。

アドバイス

ITとITセキュリティチームは、レジストラと外部のDNSプロバイダアカウントを多要素認証で保護し、内部および外部のDNSシステムのパッチ処理を完全にして、DNSの乱用や設定の変更のサインを徹底的に監視してください。また、DNSを壁の後ろに隠した配管のようにではなく、第一線のアプリケーションとして扱うようにしてください。

DNS登録とホスティングサービスを提供するクラウドプロバイダは、多要素認証を義務付け、また、潜在的な悪意のある活動（乗っ取りの試みなど）を検知するためのプロセスを確立してください。デフォルトでインストールされたDNSサービスに付属する全てのマシンイメージは、新しいDNSサーバーのバージョンがリリースされたら直ちに更新し、アップグレードの必要性を全ての既存ユーザーに通知してください。

政府のサイバーセキュリティ機関は、あらゆる種類のDNS攻撃に関してタイムリーな通知を行い、DNSインフラの安全性を確保する方法を文書化するリソースを持つようにしてください。

DNS-over-TLS（DoT）（TCP/853）

DNSの暗号化は非常に有効です。悪者が暗号化する場合を除いて。

表向きの数値上は、DNS over TLS（以下DoTと呼ぶ）は、レガシークリアテキストプロトコル向けの機密性ソリューションであり、その他多くの機密性（および整合性）に対する介入の試みに耐えてきています。DNSが盗難や中間者攻撃を受けにくくするための、数少ない現代の取り組みの1つです。

調査結果の詳細

Webブラウザがインターネットの新たなオペレーティングシステムになったことから、DoTを調査することにしました。DoTとその仲間はすべてブラウザ（またはどのようなアプリも）がユーザーの家庭、ISP、組織が選んだDNS解決方法とレゾリューションプロバイダをバイパスできるようにします。TLS上に示されることから、攻撃者にとってはDNSをコマンド&コントロールチャネルおよび脱出チャネルと利用し続けられる、優れた手段にもなります。

DoHではなくDoTの調査を選んだ理由は、DoHに比べてDoTエンドポイントを数える方がはるかに簡単だからです。クエリの標準的な方法に関して、何らかの合意があるようで、DoHを数えるのも簡単になってきています。そのため、将来的にはレポートの対象となると思われますが、今はとりあえず、Project SonarがどのようなDoTを見つけたのかに注目しましょう。

表の読み方は合っています。DoTサービスを実行しているノード数で1位となったのはアイルランドで、これは、「サプライズなしで安全にWebをブラウズできる方法を提供する、DNSベースのコンテンツフィルタリングサービス」であるCleanBrowsingを共同経営している、Daniel Cidという方のおかげです。Danielの名前はアイルランドに割り当てられているAS205157にありますが、CleanBrowsingサービス自体はカリフォルニアが営業拠点です。CleanBrowsingは実に、DoTコーパスの約50%（1,612ノード）を占めており、そのうち563ノードが米国に、また少数のサーバーがその他十数国のネットワークスペースに帰属しています。

米国とドイツ両国には、DoTサービスを示す豊富なサーバーの種類や自律システムがあります（CleanBrowsing以外に目立つものはありません）。

ブルガリアがトップ10にランクインするのは珍しいので、詳しく見てたところ、ISP向けの「メタ」サービスプロバイダーともいえるFiber Optics Bulgaria OODに多く（相対的にという意味で242件）のDoTサーバーが見つかりました。IPv4アドレスが相対的に不足していることから、242件をDoT専用にするというのは、大きな投資です。

数字は低いものの、日本がランクインするというのは興味深い結果です。日本のDoPは、ほぼすべてが1社のISPであるInternet Initiative Japanによるものです。

ご存知ない人のために一応説明すると、GoogleはDoTの分野で大手ですが、一握りのわずかなIPアドレスにDNSエクスポージャーを集中させる傾向があります（つまり、そのバーはGoogleプロパーではないということです）。CleanBrowsing（確かに、本当にどこにでも存在するのです）を除外した場合、Googleの主なエクスポージャーは、Pi-holeのインスタンスを実行している数十件のサーバー（正確にはdnsmasq-pi-hole-2.80）が残ります。この調査結果をOVとDigitalOceanに当てはめてみると、予想通り、同じPi-holeのセットアップがこれらのクラウドでも上位に入っています。

独自のDoTサーバーをホストするのに、わざわざPi-holeセットアップを実行する必要はありません。nginxインスタンスを起動し、基本的な設定を作成して、その背後に独自のDNSを設定すれば、ISPがDNSのクエリを詮索することを阻止できます。

攻撃者の視点

HeisenbergにはDoTハニーポットがありませんが、DoTというのは従来のDNSバイナリ型クエリの単なるTLSラッパに過ぎません。それをTCP/853のフルパケットキャプチャで探すと、私たち自身（！）と他のいくつかのリサーチャーが見つかったのです。あまり嬉しいことではありませんが、DoTの目的がプライバシーの保護であることを考えると、ランダムなDoTリクエストはあってはならないのです。

攻撃者はおそらく、独自のDoTサーバーを立ち上げるか、他のDoTサーバーを再設定して、フィッシング攻撃に成功して足がかりを得たら、それらのDNSバックエンドをCovert Channelとして利用するでしょう。これが、私たちがDoTを数えて整理する主な理由で、家庭用ISPおよび従来のホスティングプロバイダのIPスペースで見られるDoTは増えてきています。毎月調査を行う中で、DoTを試している人が増えているように見えます。

アドバイス

ITとITセキュリティチームは、TCP/853をブロックしてDoTとDoHのブラウザ設定をできるだけ封鎖し、組織のITポリシーをバイパスできないようにしてください。また内部（および外部）でのDoTとDoHサービスを使おうとするすべての試みを監視してください。つまり、自分自身がそれを設定している場合を除き、不正な内部DoTを禁じることが、最も安全な方法だということです。

クラウドプロバイダは、独自に立ち上げたいというユーザーに対して、マネージドDoTソリューションで、パッチされた安全なディスクイメージの提供を検討してください。（これは、組織とクラウドに関するアドバイスがほぼ反対という数少ないケースの1つです。）

政府のサイバーセキュリティ機関は、悪意のあるDoTの使用を監視し、最新情報の発表を適宜行ってください。このような機関は、DoT、DoH、DoQなどに関する公正で専門的な情報源でもあるべきです。

NTP（123）

ザ・スミスの不朽の名言「How Soon is Now（今はいつ来るの？）」です。

NTPがなければ、インターネットは今のように機能しません。これほどの権力を持つNTPは、すべてBPOCで、うぬぼれた偉そうなものだと思うかもしれません。しかし、時間に関して全てのコンピュータを同期させるという仕事は見事にこなします。Denial-of-Service攻撃に利用されるときを除いては。1985年に誕生したNTPは、唯一のネットワークベースの時刻同期プロトコルという訳ではありませんが、事実上の標準となっています。

NTPサーバーは、stratumと呼ばれる最大15レベルまである階層で動作します。私たちが毎日使用する、権威ある可用性の高いNTPサーバーがあります（多くの場合オペレーティングシステムベンダーが提供し、またtime.apple.comやtime.windows.comなど分かりやすい名前のホストで動作しています）。

事実上、ルーターや電話、またRaspeberryPiなど、つまりGPS信号をタイムソースと認識する専用機器なら、なんでもNTPサーバーになります。ただ、何かがタイムサーバーになれるからというだけで、そうなるべきだとは限りません。

調査結果の詳細

Project Sonarでは、パブリックインターネット上に163万8,577件のNTPサーバーが見つかったので、時間に関する問題は多いと言えるでしょう。編集者はそう思わないみたいなので、国やクラウド別の状況を見てみましょう。

米国には、多くのIPv4ブロック、多くのコンピュータ、そして物事をコントロールしたがる、多くのSP大手やIT企業があります。また、正当な理由なしにNTPを運営する企業も多くあります。米国がトップの座にあるのは、このような理由からです。ここで遂にロシアが2位に上がっています。理由は米国と似ていますが、ロシアの場合、大手ISP2社がエクスポージャーの40％強を占めています。莫大なIPv4スペースと人口を持つ中国3位であるというのは、企業やISPが、むやみにNTPを露出させると、必要以上に問題を引き起こすということに気付いたことを意味します。

Rapid7 Labsとしては、クラウド環境（プロバイダと顧客の両方）が、NTPを実行することの危険性を真摯に受け止め、多くのユーザーにエクスポージャーがほとんどないというのは喜ばしく思います。

エクスポージャー情報

プロトコル自体に対するメインのサポートサイトのページトップに、NTPの危険性に関する大規模で深刻な警告があるということは、NTPに危険が潜んでいるのだということはお分かりになったでしょう。最大の危険が発生するのは、増幅型DDoSに利用された場合です（UDPベースのプロトコルであるため）。NTPは現在でも使われていますが、そのような目的にはmemcachedのように、はるかに優れたサービスがあります。

NTPサーバーも、他のソフトウェア同様、脆弱性を持ったソフトウェアの集まりに過ぎません。何かをインターネットに載せると、悪者がそれをコントロールしようとします。組織が何かしらの理由でNTPサーバーを独自に実行する場合、それをパブリックインターネットに載せる必要は何もありません。また、例えそうしなければならない理由があったとしても、すべてのサブネットからのリクエストに応答するように設定する必要はありません。

なぜこのようなあら探しをしているのでしょうか。パッチ処理をしないというのも、もう1つの問題です。さらに、ネットワークセットアップについて攻撃者に情報を与えているかも知れないという問題もあります。NTPコーパスでは、内部ネットワークインターフェース上のプライベートIPアドレススキームが25万5,602件（15.5%）で見つかりました。

150万件以上のNTPサーバーが、オペレーティングシステムやバージョンに関するヒントを公開しているのです。合計で、18万410件（11%）がNTPの正確なバージョンとビルド情報を公開しており、約4,000件が正確なリリース日も提供しています。

NTPデバイスのミックスには、[不]健全なリモートコード実行、情報漏洩、ローカルサービスDoS、増幅型DDoSのミックスが広がっています。

もし本セクションの初めに、「ただのNTPサーバじゃないか」と思っていたのであれば、そうではないということを少しでも説得できたのなら幸いです。

アドバイス

ITとITセキュリティチームは、ファイアウォールの背後でNTPを使用し、適切なパッチ管理を行ってください。外部でNTPを実行する必要がある場合は、対話できるホストやネットワークを制限してください。

クラウドプロバイダは、露出するNTPを引き続き必要最低限に抑え、（インターネットの外での）NTPの安全な実行方法についてユーザーにガイダンスを提供してください。

政府のサイバーセキュリティ機関は、NTPの新たな脆弱性や、NTPに対する活発なDoS作戦が発見された場合、速やかに通知してください。NTPをインターネットに露出することの危険性や、さまざまなNTPサービスの安全な設定方法に関する教材を配布できるようにしてください。