PHPサンドボックスのセキュリティ問題

Question

私はPHP Webアプリケーションハニーポットのサンドボックスに取り組んでいます。PHPサンドボックスはPHP RFI攻撃の一部として挿入されました。これは、ファイルを安全な環境で実行し、PHPスクリプトの出力を埋め込んで結果を返します。攻撃者をだまして、これは本物の対応であり、攻撃の次のステップに進みます。

サンドボックスを構築するために、Advance PHP Debugger（ADP）を使用しました。rename_functionおよびoverride_functionを使用して、脆弱性PHP =関数が書き直されました。exec、disk_free_spaceなどの一部の関数は、偽の返信を送信するように書き直されました。他のすべての関数は、何も返さないだけです。こちら完全なリスト考慮された機能の。

また、入力スクリプトは、サンドボックスで最大10秒間のみ実行されます。その後、サンドボックスプロセス全体が強制終了されます。

このリストで十分ですか？これにより、サンドボックスはWebアプリのハニーポットの一部になるのに十分なほど安全になりますか？
このような関数呼び出しをブロックする以外に、取るべきセキュリティ対策はもうありますか？
結局、これはハニーポットです。したがって、実際の返信にできる限り近い返信をお願いします。したがって、dns_check_recordやgethostbynameなどのDNS関数呼び出しをブロックすることで、スクリプトの実行範囲を不必要に制限しています。（そもそもなぜそれらが存在するのかはわかりません）

要するに、どの要素をリストに追加/リストから削除すべきかを知りたいのです。
これに対処する方法に関するその他の提案/アドバイスは高く評価されます。

Yoav Aner · Answer

私はPHP=エキスパートであるとはほど遠いので、私のコメントは具体的というよりは一般的です。

おそらく完全ではないかもしれませんが、状況によって異なります。 anyホワイトリスト/ブラックリストのアプローチが100％正確になるとは思いません。 false positivesまたはfalse negativesのケースは常に存在します。つまり、常にhits（スクリプトが防御を貫通できる）とmisses（つまり、スクリプトを正常にブロックするが、そのような方法で）の間で常にバランスを取っています。詳細な分析はできません）。 PHPには何千もの異なる呼び出しと順列が必要であるため、完全なリストを作成することは非常に困難です。とはいえ、一目でリストを確認しても、出発点としては問題ありません。繰り返しますが、私のphpの経験制限されています。
「Webアプリの一部にする」と言ったときの意味はわかりませんが、リモートで接続されているものや、実際のデータや実際の本番アプリケーションに近接しているものを埋め込むことはお勧めしません。これがハニーポットである場合は、おそらく可能な限り分離に保つ必要があります。次のようなことを考慮する必要があります。
- 定期的に「更新」される専用ハードウェアマシンでこれを実行する（再イメージ化、ゼロから構築）
- 外の世界以外に接続させないでください
- 機密性の高い（またはそれほど機密性の低い）データを保存しないでください
- すべてのアクセスをログに記録し、詳細なログで外部ファイアウォールを使用する
- 内部OSシステムログを使用する
- 任意のログでリモートから奇妙なものまで監視します
- 外部接続の速度を調整することを検討してください
システムが十分に隔離されている場合、それ自体以外に残る主なリスクは、他のシステムに対するものです。攻撃者がphp保護層を無事通過したと想定すると、ハニーポットを使用して他のシステムに外部攻撃を仕掛けることができます-スパム、サービス拒否、ボットネットの一部としての動作など。これが、孤立した状態に保ち、それに目を離さずに、ゴミを捨ててゼロから開始することをお勧めする理由です。
残念ながら、1ですでに取り上げた以上のことには答えられません。
2を参照してください。

symcbean · Answer

あなたのアプローチは私にはあまり意味がありません。

一般的な攻撃ベクトルを無効にして、ハニーポット（つまり、安全ではないように見えるシステム）を作成するとします。

攻撃者をだまして、これが本物の応答であると信じ込ませたい

これは、すでに特徴付けた攻撃の代わりに応答を使用できることを意味します。また、動作をモデル化しようとしているシステムに対して、非常に異なるソフトウェアスタックを実行します。

せいぜい、これは多大な労力になるでしょう。代表的なものとはかけ離れたものになる可能性が高く、モデリングしているシステムの脆弱性を公開せず、これを攻撃者に公開します。あなたのリストは、安全なPHPインストールのために無効化/ラップするための完全なリストではありませんが、それがポイントではありません。

標準に戻すことをお勧めしますPHPビルドして、ハニーポットを全体としてカプセル化および監視する方法について考えます。ハニーポットを仮想マシンに実装することをお勧めします（これは、他の場所にコピーして、調査し、すぐにオフラインにし、ビルドを変更します）、プロキシを作成し、リモートロギングと（ほぼ）継続的な整合性チェックを使用して、すべてのサーバートラフィックをログに記録します。ラップキーPHP =関数/ログ付きの構成-ただし、無効にしないでください。