私は自分のネットワークを外部からハッキングしようとして、ポート転送がセキュリティ上の欠陥となる理由を学びました。

私はプロのレッド チーム担当者でもセキュリティ研究者でもありませんが、システム エンジニアリングと DevOps にバックグラウンドがあるため、Linux、ネットワーキング、ファイアウォール、仮想化、インフラストラクチャ セキュリティの作業に多くの時間を費やしています。当然のセキュリティ ルールはすでに知っていました。

私が知りたかったのは、実際のネットワークが私が持っていると思っていたネットワークとまだ一致しているかどうかでした。時々リモートからアクセスする必要があるサービスのために、ルーターにいくつかのポート転送ルールがありました。私はそれらのほとんどが何のためにあるのかを知っていましたし、セットアップは合理的に制御されていると考えていました。次に、ネットワークの外側からパブリック IP をスキャンしたところ、忘れていたものがいくつか存在することがわかりました。

Nmap は予想以上のものを見せてくれました

使わなくなったサービスを見つけた

まず、パブリック IP アドレスに対して単純な Nmap スキャンを実行しました。最初のいくつかの開いたポートはまさに私が期待していたものであり、サービスを認識し、それらが公開された理由もわかりました。その後、Nmap は私が長い間考えもしなかったポートを見つけ始めました。かなりの数がありました。そのうちの 1 つはポート 9000 の MinIO でした。その後 SeaweedFS に移行したため、MinIO は使用しなくなり、そのデプロイメントは事実上放棄されました。

ただ忘れていただけでした。サービスはまだ実行中であり、転送ルールもまだアクティブでした。それはまさに私が外部スキャンで見つけてほしかった種類のものでした。どのサービスを意図的に公開したかはわかっていましたが、使用を中止した古い実験やサービスについて、同じように頭の中に保管していませんでした。それはホームラボでは見落としがちなことです。アクティブに使用しているものと現在保守しているものを覚えています。数か月前の実験で忘れ去られたサービスは、はるかに見落とされやすくなります。

予期しないポートを特定した後、Nmap のサービス検出を使用して、その背後で実際にリッスンしているものを特定しました。

これにより、外部システムが認証なしで何を識別できるのかをより明確に把握できるようになりました。提供されているプロトコルを確認し、サービスによって十分な情報が明らかになった場合には、その背後にあるアプリケーションを特定することができました。その時点で、スキャンを忘れられた転送ルールのリストとして扱うのをやめました。私は、公開されている各サービスを個別に調査し始めました。そこでさらに興味深い発見があった。

公開されているアプリケーションを調べ始めた

ポート 5000 には私が見落としていた問題がありました

私が調査したサービスの 1 つは、ポート 5000 でリッスンしていました。Flask アプリケーションは私にとって馴染みのあるものであり、おそらくそれが、最初にこのアプリケーションに注意を向けなかった理由の 1 つでした。ネットワークの外部からサービスを開いたところ、依然として HTTP 経由でログイン ページが提供されていることがわかりました。 HTTPS へのリダイレクトはありませんでした。それから私は使用しました curl ページを調べると、HTML 内に次のことが見つかりました。

アプリケーションは HTTPS を優先しないように明示的に構成されています。つまり、HTTP エンドポイントを介して認証する人は誰でも、トランスポート暗号化なしで資格情報を送信することになります。そのトラフィックを観察できる攻撃者は、これらの資格情報を取得する可能性があります。

問題は特殊な脆弱性ではありませんでした。サービスが正常に動作したため、小さな構成の詳細が残されました。私のネットワーク内では、それについて考える理由はあまりありませんでした。インターネットで見ると、状況は大きく異なっているように見えました。

調査すればするほど、根本的な問題が明らかになってきました。個々のサービスは必ずしも悲惨なものではありませんでした。さらに大きな問題は、それらの一部はもはや公開されるべきではなかったということでした。正当な理由で転送ルールを作成しました。一部は実験用、一部は一時的なリモート アクセス用、そして一部は削除が緊急ではなかったために単に残されていました。

経験によって構成のドリフトが解消されるわけではありません。これらの転送ルールを作成したとき、私は自分が何をしているのかを知っていました。また、サービスを公開することに伴うリスクも知っていました。私が知らなかったことは、それらの古い決定の一部がまだ有効であるということでした。だからこそ、外からの視点は貴重なのです。構成を覚えている環境ではなく、実際に存在する環境をテストします。

ヘッドスケールのおかげで露出を減らすことができました

これらのサービスの一部へのリモート アクセスのみが必要でした

公開されたサービスの調査が完了したら、それぞれのサービスを公開する必要があるかどうかを検討し始めました。そのうちの何人かにとって、答えは「ノー」でした。私はすでにプライベート ネットワークに Headscale を使用しているため、すべてのアプリケーションをルーター経由で公開することなく、この問題を解決できました。古いサービスをクリーンアップし、不要になった転送ルールを削除し、プライベート サービスをヘッドスケール ネットワークの背後に移動しました。

NAS のポート転送を停止: リモートからファイルにアクセスするより安全な方法

これは、ほとんどの人が未だに無視している NAS セキュリティ機能の 1 つです

これにより、実際に必要なリモート アクセスを維持しながら、インターネットに直接公開されるアプリケーションの数が減りました。私は真の理由がある場合には公開を続けましたが、ルールの説明がはるかに簡単になりました。残りの公共港がそれぞれ存在する理由を説明できました。それは単に港がそこにあることを知っているよりもはるかに良い立場にありました。

ポート転送を恐れる必要はありません

ポート転送は本質的に安全ではありません。サービスを一般公開する正当な理由はたくさんあります。問題は、転送ルールは作成が簡単で、非常に忘れられやすいことです。ポート 9000 の MinIO インスタンスは完璧な例です。私は数か月前に MinIO から移行していましたが、サービスとその転送ルールはまだそこに残っていて、発見されるのを待っていました。これは、経験豊富な管理者でも見逃す可能性がある種類のことです。現在、私はネットワークの定期的な外部テストを設定して、パブリックな攻撃対象領域が私が考えているものと一致していることを確認しています。これは私のメンテナンス ルーチンへの小さな追加ですが、構成ファイルでは得られないもの、つまりインターネットが実際に到達できる範囲についての独立したビューを提供してくれます。