SELinuxに関する前回の記事の公開後、このセキュリティサブシステムの「実用性を実際に証明する」ための多くの提案がありました。 テストすることにしました。 これを行うために、一般的な構成の3つの脆弱なスタンドを作成しました（CentOS 5.8のDamn Vulnerable Web Application）。 それらの違いは、SELinux設定のみでした。最初の仮想マシンでは無効になっており、他の2つの仮想マシンではターゲットポリシーと厳密なポリシーが適用されていました。
この構造では、仮想マシンのスタンドの侵入がテストされました。 結果を見てください？
ただし、最初にノードの設定を見てみましょう。 テンプレートを作成するために、「電球」（ LAMP ）がデプロイされたCentOS 5.8オペレーティングシステムが使用されました。 セットアップの過程で、この場合に起こりうるすべての典型的な間違いをしようとしました：スーパーユーザー権限でデータベースに接続し、デフォルトですべてをセットアップしました。 したがって、我々は単一の出発点でイベントの開発の3つの行を再作成しようとしました。
ソースサーバーは、標準のyumユーティリティを使用して、可能なすべての更新を受け取った赤ずきんちゃんの腕の中でApacheです。 もちろん、このおとぎ話は祖母なしにはできませんでした。MySQLデータベースはノードにインストールされています。 この優れた会社は、非常に脆弱なWolf- Damn Vulnerable Web Applicationによって補完されています。このWebアプリケーションを使用して 、他のほぼすべてのキャラクターにアクセスできます。 しかし、3人のハッカーのうち2人のサーバーで、銃を持ったハンターが待機しています-SELinuxは、怪しい活動で余分な手足を撃ちます。
安全でないサーバーでは、SELinuxは無効モードになっています。 これは、 Site-Which-Must-Not-Callの指示からの古典的なソリューションです。 すべてがその場所にあり、httpdとmysqldにはデフォルトの構成があります。 したがって、ノードには追加の保護はなく、すべてサービス自体の安定性に依存します。
Webサーバーを保護するためのオプションの1つとして、ターゲットポリシーでSELinuxを使用しました。 私はそれに何も変更を加えませんでした。ソリューションは、ベンダーが提供する形式で「箱から出して」そのままです。 サービスは準備されたドメインで実行され、「標準操作」のフレームワーク内で動作します-Red Hatエンジニアの観点から。
最後の構成は「厳格な」SELinuxポリシーであり、定められた考え方に従って、ホワイトシートの原則に基づいて動作します。 許可されていないものは禁止されています。 私は、必要なコンテキストでファイル部分をマークしようとしましたが、非常に控えめに特権を割り当てました。 このセットアップは、狂信的ではないものの、かなり「ねじれた」システムを提供します。
Positive Technologies（Habrではki11obyteとして知られています ）の同僚に侵入テストを依頼しました。 彼は言い続けます。
SELinuxが無効になっているマシンから始めましょう。 サーバーは当初脆弱であると位置付けられていたため、Webシェルを入手することは難しくありませんでした。
リクエストのContent-Typeフィールドのみをチェックする、サーバーに画像をアップロードする形式が与えられます。 PHPでWebシェルに入力し、Content-Type（この場合はBurpSuiteを使用）をimage / jpegに置き換えます。
シェルはテストに合格し、サーバーにアップロードされます。
この場合、構成されたSELinuxもシステムを保護できませんでした。
次に、Webシェルを実行する必要があります。 これを行うために、他のスクリプトをダウンロードする機能を持つ脆弱なスクリプトをサイト上で見つけます。
ファイルは各マシンで正常に接続されました。 したがって、SELinuxはWebアプリケーションのエラーから私たちを保護しません。
これで、ロードされたWebシェルを介して安全にコマンドを実行できます。
または、逆接続を使用して、より使い慣れたコンソールを取得できます。
これで、SELinuxが有効になっているマシンのキュー。 再びWebシェルを取得しますが、少しがっかりしました。ソケットを作成したり、lsを実行したりするための十分な権限がありません。
ただし、ディレクトリを一覧表示する機能がないにもかかわらず、ファイルを簡単に参照できます。
ところで、リストはPHPを使用して実装されました。
さらに、ファイルを作成し、実行可能にして実行することもできました。
次のステップは、DBMSをキャプチャすることでした。 Webシェルを使用して、MySQL Webアプリケーションの構成ファイルをスパイし、それを使用して接続します。
SELECT LOAD_FILEクエリ（ '/ etc / passwd'）を使用すると、ファイルを読み取ることができます。 ファイルを一時ディレクトリに簡単に書き込むこともできます。SELECT1 INTO OUTFILE '/ tmp / ololo'。 本当に奇妙であることが判明したのは、作成されたファイルに対するかなり珍しい権利です。
SELinuxをオンにして構成したマシンでは、違いは見つかりませんでしたが、多少失望しました。
-
実験の結果、次の結論に達しました。 まず、脆弱なアプリケーションの選択に失敗しました。DVWAはSELinuxの悪い例です。 「脆弱性」の大部分は、httpd_tドメインにすでにあるアクセスを対象としています。 その結果、不幸な赤ずきんちゃんと問題のない同意したアパッチをどのように助けるかは完全に理解できません。 唯一の適切な解決策は、逆接続を禁止して、ほとんどのバイナリファイルへのアクセスを制限することでした。 他のすべての場合、攻撃者のアクションは、標準設定のセキュリティサブシステムの範囲内に収まりませんでした。
第二に、Webプロジェクト用にSELinuxをセットアップすることは非常に時間のかかる作業であり、強力な知識とかなりの努力が必要であることは完全に明らかになりました。 注：「Webサーバーを保護する」だけでなく、プロジェクト全体を真剣に保護することです。 独自のコンテキスト相互作用ポリシーを作成することは可能ですが、これの適切性は疑わしいです。 私の個人的な意見：phpとhttpdの適切な構成と定期的な更新に依存します。
そのため、SELinuxは少なくともシステム内の異常なアクティビティを記録できます。 そして、慎重に構成すれば、許可されていないアクションも禁止できます。 ただし、残念ながら、コードエラーや不適切なアプリケーション設定からWebプロジェクトを保護することはできません。