ポートが開いているという理由だけでサーバーが危険にさらされていると考えるべきですか？

Question

今日、私はマンドリルでのセキュリティインシデントの通知を受け取りました。最初は心配していましたが、詳細を調べた後、なぜこれが注目に値するものであるのかについて混乱しました。

要約すると、マンドリルはEC2セキュリティグループにいくつかの変更を加えたため、ロギングサーバーの一部のポートが数週間インターネットにアクセス可能になったようです。

3月10日、ボットネットで使用するためにMandrillの内部ロギングサーバーに対して自動化された試みが行われた証拠を発見しました。影響を受けたサーバー（ネットワークトラフィックログやサーバー上に存在するファイルを含む）の分析は、これらの試みが失敗したことを示しています。サーバーがそれらに格納されたデータにアクセスするために標的にされたという兆候はありません。

この問題を調査したところ、この攻撃の機会は、2月20日に実施したファイアウォールの変更によるものであり、一部のMandrillのサーバーへのアクセスをより細かく制御できることがわかりました。マンドリルのインフラストラクチャの一部はアマゾンウェブサービス（AWS）でホストされており、EC2セキュリティグループを使用してアクセスを制御しています。セキュリティグループに1つの変更が加えられ、影響を受ける予定のサーバーよりも多くのサーバーが含まれていました。その結果、マンドリルの内部アプリケーションログをホストするサーバーのクラスターは、内部のみのアクセスを許可するのではなく、パブリックにアクセスできるようになりました。

現在、私たちはすべてボットネットを常に扱っており、マシンをボットネットから合理的に安全に保つ方法はよく知られています。特に、私が実行するもののほとんどすべてが公開されており、何百万ものボットネットの試みが見られますが、ログエントリの生成以外には何も成功しません。

ただし、このため、すべてのAPIキーを無効にして変更することを全員に推奨しています。個人的には12個近くのアクティブなAPIキーを持っていますが、変更が必要な場所でこれらすべてを変更するには、午後のほとんどの時間がかかります。

私の個人的な考えは、彼らはこれに対して大規模に過剰反応したということです。しかし、私はすべてを知っているわけではありません。ここで単にポートを開くだけで妥協の可能性があると考えられる理由はありますか？

Lie Ryan · Accepted Answer

開示を読むと、開いているポートは実際にはランダムなポートではなく、外部の世界に直接公開されるように設計されたことのない特定の内部サービスがリッスンしていたポートであることが起こります。その内部サービスに脆弱性がある場合、攻撃者は指定された期間内にサービスを使用するユーザーのAPIキーを取得できる可能性があります。

彼らは攻撃が標的型攻撃ではなく自動化された攻撃のように見えることに注意していますが、高度な攻撃者は多くの場合、非常に目立つ自動化攻撃を使用して、発生している別の秘密の標的型攻撃からサーバーおよびシステム管理者の注意をそらすことを考慮する必要があります同時に、つまり、多くの注目を集める大きなDDoSは、単なる気晴らしです。

巧妙な攻撃者は、重要なデータを誰も侵害していないように見せかけるためにシステムへの特権を獲得できた場合、その痕跡を消してしまう可能性があります。そのため、実際にクエリされているデータの証拠が見つからなかったとしても、APIキーの変更を推奨しています。特に、これは侵害されたログサーバーであり、sysadminは通常ログを使用して侵害を検出するため、侵害されたログサーバーは実際に起こっていることを隠すことができます。

巧妙な攻撃者はまた、システムにバックドア/ルートキットを残して、後から誰もが落ち着いたと思ったときにシステムに再び入ることができるようにし、セキュリティ境界の内側からよりゆったりとしたペースで実際の攻撃を行うことができます。これは非常に危険です。これが、関係するマシンを廃止する理由です。

あるいは、セキュリティについての疑いがあるために購入の意思決定の垣根を握っている潜在的なセキュリティ意識の高い顧客へのショーとしてこれを行っているかもしれません。これにより、顧客に影響を与える可能性のある脆弱性がある場合に会社が母親を維持しないことが安心できるため、顧客がサービスを利用することを決定する可能性のある顧客の態度が変わる可能性があります。

ここで単にポートを開くだけで妥協の可能性があると考えられる理由はありますか？

はい、開いているポートは、外部で使用するように設計されていない内部サービスを公開します。サービスは信頼できるマシンからのみアクセス可能であると想定されていたため、内部使用を目的としたサービスは、一般に公開されているサービスのセキュリティ強化に欠けていることがよくあります。たとえば、内部サービスは、信頼済みネットワーク内での通信にSSLを使用しない場合や、信頼できる送信者がすでに必要な検証を行っていると想定しているため、入力を十分に検証しない場合や、認証なしで使用できる管理コマンドがある場合があります。必要な認証はすべて公衆向けサービスによって行われていると想定しているためです。