一般に、「攻撃」という用語は、組織に対するサービス妨害の試みを意味するようになっています。これはおそらく、DDoS攻撃が頻繁かつ大規模に発生し、著名な組織に深刻な影響を及ぼしてきたためです。その結果、相次ぐ報道によって、多くの人々の間で「攻撃」という用語が、組織を標的とするDDoS攻撃の試みという1種類の攻撃のみを意味するものとして定着しました。
しかし、DDoSに先立って行われる攻撃はほかにもあります。そうした攻撃を放置することで増え続ける「シングボット」の大群がもたらす脅威に対処し始めるには、まずこれらの攻撃に目を向ける必要があります。

現在、アナリストも評論家も、ネットワークに接続されるモノの数が急速に、ほぼ指数関数的に増加すると予測しています。攻撃者が一般消費者向けのモノを悪用したというセンセーショナルな報道から、こうした攻撃が実際以上に多発しているように見えるかもしれません。しかし実際には、組織によるIoTデバイスの導入が急増しており、それに伴ってデバイスへの攻撃も増えています。なかでも特に目につきやすいものとして、道路標識がどれほど頻繁に「ハッキング」されているかを考えれば、「モノ」が実際にどれほど広く普及しているかがすぐにわかります。
ある最近の調査によると、家庭ではなく組織内にあるデバイスの平均数は、今後2年間で倍増する見込みです。同じ調査では、それらすべての所在を把握している組織はわずか28%にすぎないことも指摘されています。つまり、大半の組織は、組織内でインターネットに接続されているデバイスやモノの一部しか把握していません。金融業界を対象とした2016年のSANS Instituteの調査でもほぼ同様の結果が示されており、IoTを含むデバイスを完全に可視化できているとの回答は40%未満で、少なくとも部分的に可視化できているとの回答は約半数でした。
With F5 Labsの調査によると、そうしたデバイスを狙う攻撃は年間1,373%という驚異的な割合で増加しています。膨大な数のthingbot予備軍に対し、現在どのようなセキュリティ対策を講じているのか、改めて考える必要があります。ご記憶のとおり、Arxan/IBMの調査では次のように指摘されています。「実に44%が、攻撃を防ぐために何もしていないと回答しました。これらのアプリを介した侵害については懸念しており、IoTアプリでは58%、モバイルアプリでは53%に上ります。それでも、対策は何も講じていません」
突拍子もないと思われるかもしれませんが、まずは最初の「勧誘」攻撃を阻止することから始めるのがよいでしょう。一般的には、SSHとtelnetへのアクセスを厳しく制限して管理プレーンを強化し、存在する可能性のあるWebインターフェースを保護することを意味します。
というのも、こうしたデバイスを侵害する主な手口は依然として、デフォルトパスワードを使ってコマンドラインにアクセスするか、脆弱なWebインターフェースを悪用することだからです。結局のところ、telnetスキャンが増加しているのはそのためです。攻撃者や侵害されたデバイスは、ほかのデバイスをスキャンし、既知のデフォルト認証情報を使ってアクセスを試みたうえで、そのデバイス自体も感染させてボットネットに取り込みます。

注意を払うべき重要な対象は、アウトバウンドトラフィックです。侵害されたデバイスが既存の多数のThingbotに加わり、ネットワークの外部(または内部)にある他のデバイスを悪用しようとする際に、その存在が明らかになる可能性があるためです。過剰なトラフィックや接続試行など、異常な動作を示す「新しい」デバイスを監視することで、ネットワーク内にすでに存在し、対処が必要な悪意あるデバイスを特定できる可能性があります。
According to 最近の調査によると、94%がIoTの脅威への対処を従来型のネットワークファイアウォールに依存しています。しかし、脅威の多くは、すでに侵害されたデバイスや、ネットワークファイアウォールだけでは十分に保護されていないWebインターフェースを介して、自社ネットワークの内部から発生している可能性があります。そもそも、こうしたデバイスの所在を把握していない人の割合を考えると、ファイアウォールが宛先IPアドレスに基づいてアクセスをブロックしている可能性は低いと考えられます。また、攻撃者は攻撃元を容易に変更・分散できるため、送信元IPアドレスに基づくブロックはあまり効果的な対策ではありません。
そのため、WAFを活用して管理インターフェースとユーザー向けアプリを保護し、攻撃者に容易な侵害経路を与えかねないインターフェース上の一般的なWeb脆弱性を悪用する試みを阻止してください。マルウェアを仕込める脆弱性であれ、単にコマンドラインへのアクセスを可能にする手段であれ、管理インターフェースを狙うWebベースの攻撃は、拡大を続けるThingbot軍団にデバイスを取り込む最短経路となる可能性があります。
また、ペイロード検査が必要となる場合があるMQTTやCoAPなどのIoTプロトコルを悪用した、デバイスの取り込みの試みは検出できない可能性があります。現在の攻撃の大半は、従来からデバイス管理に使用されているプロトコル(telnetやSSHなど)を悪用していますが、MQTTを介してデバイスを直接攻撃する脅威もすでに認識されています。実際、OWASPはすでにプロジェクトを開始しており、Webセキュリティの推進とほぼ同じ方法でIoTのセキュリティ強化を支援しています。侵害につながる可能性のあるネイティブプロトコルの悪用からデバイスを保護するために、IoTゲートウェイの導入を検討することをお勧めします。
要約すると、IoTデバイスを保護するために、以下の点をご検討ください。
- デフォルトのパスワードを変更する(予防)
- telnet/SSHアクセスを制限する(予防)
- Webインターフェースを保護する(WAFを使用)(予防)
- IoTゲートウェイを導入する(予防)
- ネットワーク内の異常なトラフィックを監視(検知)
- アウトバウンドトラフィックの新たな送信元を監視する(検知)
現時点では、IoTデバイスへの攻撃は避けられないように思われます。すでに膨大な数のIoTデバイスがネットワークに接続され、インターネット経由でアクセス可能になっています。セキュリティ対策が不十分であることも広く知られているため、攻撃者にとって見過ごせないほど魅力的な標的です。ネットワーク内のIoTデバイスを問題の一端にしないことが重要です。そのためには、「大規模攻撃」に先立つ攻撃を検知し、防止する必要があります。
いつか自社のデバイスからDDoS攻撃を受けるようなことになれば、かなり不名誉な事態になりかねないからです。
SANSには、IoTを狙う攻撃の検知に関する優れた資料もあります。ぜひご一読ください。
著者について

Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。
Lori Mac Vittieのその他のブログ記事関連するブログ記事

F5 Application Study Tool:OpenTelemetryによるF5 BIG-IP環境の監視
F5の新しいオープンソースツールは、BIG-IP環境を詳細に可視化し、データを追跡するとともに、強力でカスタマイズ可能なインサイトを得るための基盤を提供します。
F5 BIG-IPでAI防御を実現
F5 BIG-IP Advanced WAF、BIG-IP APM、BIG-IP SSL Orchestratorが、生成AIアプリ向けに包括的なセキュリティソリューションを提供する仕組みをご覧ください。
F5 Advanced WAFによるGraphQL APIの保護
ここ数年、多くの組織がデジタルトランスフォーメーションを進めており、COVID-19のパンデミックによってその動きは加速しています。
アプリケーションサービスの現状 通信業界版:リーダーとしての台頭
通信ネットワークが進化し、さまざまな業界の幅広いユースケースに対応するなか、通信業界の回答者がテクノロジーリーダーとしての存在感を高めていることがわかります。
デジタルトランスフォーメーションは、単なるペーパーレス化ではない
デジタルトランスフォーメーションは、単なるペーパーレス化ではありません。真のモダナイゼーションにアプリケーションアーキテクチャとセキュリティの再構築が必要な理由を、F5ブログでご覧ください。
やめましょう。もう本当にやめましょう。HTTPSはHTTPより高速ではありません。
もうやめましょう。HTTPSはHTTPより高速ではありません。プロトコルのパフォーマンスに関する微妙な違いと、暗号化トラフィックを適切に最適化する方法については、F5ブログをご覧ください。