システム管理者が知っておくべき PHP セキュリティ慣行

システム管理者が知っておくべき PHP セキュリティ慣行
PHP は、広く使用されているオープンソースのサーバー側スクリプト言語です。 Apache Web サーバーは、HTTP または HTTPS プロトコルを通じてファイルやコンテンツにアクセスする利便性を提供します。サーバー側のスクリプト言語が不適切に構成されていると、あらゆる種類の問題が発生する可能性があります。したがって、PHP を使用する場合は注意してください。以下は、システム管理者が PHP を安全に構成するための 25 の PHP セキュリティのベスト プラクティスです。
PHP セキュリティのヒント用に提供されるサンプル環境

DocumentRoot: /var/www/html
デフォルトの Web サーバー: Apache (Apache の代わりに Lighttpd または Nginx を使用できます)
?デフォルトの PHP 構成ファイル: /etc/php.ini
?デフォルトの PHP ロードモジュール設定ディレクトリ:/etc/php.d/
?サンプル PHP セキュリティ設定ファイル:/etc/php.d/security.ini (使用する必要があります)このファイルを作成するにはテキスト エディタを使用します)
オペレーティング システム: RHEL/CentOS/Fedora Linux (関連する手順は、Debian/Ubuntu または OpenBSD などの他の Linux ディストリビューションと一致している必要があります/FreeBSD/HP-UX およびその他の Unix と互換性があります)のようなオペレーティング システム)。
デフォルトの PHP サーバー TCP/UDP ポート: なし

この記事にリストされているほとんどの操作のコードを記述するとき、これらの操作は、bash シェルまたはその他のコマンドを実行している root ユーザーによって実行されると想定されています。その他の最新シェル:
$ php -v
出力例:
PHP 5.3.3 (cli) (ビルド: Oct 24 2011 08:35:41)
Copyright (c) 1997-2010 The PHP グループ
Zend Engine v2.3.0、著作権 (c) 1998-2010 Zend Technologies
デモンストレーションの目的で、次のオペレーティング システムを使用します:
$ cat /etc/redhat-release
サンプル出力:
Red Hat Enterprise Linux Server リリース 6.1 (Santiago)
ベスト プラクティス 1: 相手を知る

PHP ベースのアプリケーションは、さまざまな種類の攻撃に直面します。いくつかの異なる種類の攻撃があることに気付きました。

1. XSS: クロスサイト スクリプティングは、攻撃者がユーザーの情報を盗むために悪用できる Web PHP アプリケーションのセキュリティ脆弱性です。 XSS 攻撃を回避するために、Apache を構成し、より安全な PHP スクリプト (すべてのユーザー入力を検証) を作成できます。

2. SQL インジェクション攻撃: これは、PHP アプリケーションのデータベース層におけるセキュリティの脆弱性です。ユーザー入力が不適切にサニタイズされると、アプリケーションは任意の SQL ステートメントを実行できます。 Apache を構成し、SQL インジェクション攻撃を回避するために安全なコード (すべてのユーザー入力を検証および変換) を作成できます。 PHP では、SQL クエリを送信する前に mysql_real_escape_string() という関数を使用してパラメータを変換するのが一般的です。

3. ファイルのアップロード: 訪問者がサーバーにファイルを配置 (ファイルをアップロード) できるようになります。これにより、ファイルの削除、データベースの削除、ユーザー詳細の取得など、多数のセキュリティ上の問題が発生する可能性があります。 PHP を使用すると、ファイルのアップロードを無効にしたり、セキュリティ コード (ユーザー入力を検証し、PNG や GIF などの画像ファイル タイプのみを許可するなど) を記述したりできます。

4. ローカル ファイルとリモート ファイルを追加する: 攻撃者はリモート サーバーからファイルを開いて、任意の PHP コードを実行できます。これにより、ファイルのアップロード、削除、バックドアのインストールが可能になりました。 PHP は、リモート ファイル実行機能を無効にするように設定できます。

5. eval(): 文字列を PHP コードとして評価します。攻撃者は多くの場合、この機能を使用してコードやツールをサーバー自体に隠します。 eval() を無効にするように PHP を構成できます。

6. シーサーフ攻撃 (クロスサイト リクエスト フォージェリ、CSRF): この攻撃は、エンド ユーザーに、現在 ID を認証している Web アプリケーションに対して有害なアクションの実行を強制します。一般のユーザーの場合、CSRF 攻撃が成功すると、エンド ユーザーのデータと操作が危険にさらされます。ただし、対象となるエンド ユーザーが管理者アカウントを使用している場合、Web アプリケーション全体が危険にさらされる可能性があります。


2 番目のベスト プラクティス: 組み込み PHP モジュールを検索する



コンパイルされた PHP モジュールのセットを表示するには、次のコマンドを入力します:
# php -m


出力例:



[PHP module]
apc
bcmath
bz2
calendar
Core
ctype
curl
date
dom
ereg
exif
fileinfo
filter
ftp
gd
gettext
gmp
hash
iconv
imap
json
libxml
mbstring
memcache
mysql
mysqli
openssl
pcntl
pcre
PDO
pdo_mysql
pdo_sqlite
Phar
readline
Reflection
セッション
shmop
SimpleXML
ソケット
SPL
sqlite3
標準
suhosin
tokenizer
wddx
xml
xmlreader
xmlrpc
xmlwriter
xsl
zip
zlib


[Zend モジュール] ]
Suhosin


パフォーマンスとセキュリティを強化するために、モジュールの数を減らした PHP を使用することをお勧めします。たとえば、次のように構成ファイルを削除 (削除) するか、/etc/php.d/sqlite3.ini という名前のファイルの名前を変更 (または移動) することで、sqlite3 モジュールを無効にできます:
# rm /etc/ php.d /sqlite3.ini


または
# mv /etc/php.d/sqlite3.ini /etc/php.d/sqlite3.disable


他のコンパイル済みモジュールは、PHP のシン構成を再インストールすることによってのみ削除できます。 php.net から php ソース コードをダウンロードし、次のようにコンパイルして、GD、fastcgi、MySQL をサポートできます:
./configure --with-libdir=lib64 --with-gd --with-mysql - -prefix =/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includeir=/usr/ include - -libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --cache-file=。 ./ config.cache --with-config-file-path=/etc --with-config-file-scan-dir=/etc/php.d --enable-fastcgi --enable-force-cgi-redirect


詳細については、「php をコンパイルして Unix 系オペレーティング システムに再インストールする方法」 (http://www.php.net/manual/en/install.unix.php) を参照してください。

3 番目のベスト プラクティス: PHP 情報漏洩を制限する

PHP 情報漏洩を制限するには、expose_php を無効にします。 /etc/php.d/secuity.ini を編集し、次のコマンドを実行します。

expose_php=Off 有効にすると、expose_php はサーバーに PHP がインストールされていることを外部に報告します。これには、サーバーに PHP のバージョンが含まれます。 HTTP ヘッダー (X-Powered-By: PHP/5.3.3 など)。 PHP によって識別されるグローバル一意識別子 (GUID、例 http://www.php.net/?=PHPE9568F34-D428-11d2-A769-00AA001ACF42 を参照) も表示されるため、これらをサポートするサイトの URL の末尾に追加されます。 PHP を実行すると、対応するロゴが表示されます。 Expose_php を有効にすると、次のコマンドを使用して PHP バージョンを表示できます:

$curl -I http://www.cyberciti.biz/index.php サンプル出力:

HTTP /1.1 200 OK
X-Powered-By: PHP/5.3.3
Content-type: text/html/charset=UTF-8
Vary: Accept-Encoding, Cookie
X-Vary -オプション: Accept-Encoding;list-contains=gzip,Cookie;string-contains=wikiToken;string-contains=wikiLoggedOut;string-contains=wiki_session
Last-Modified: Thu, 03 Nov 2011 22:32:55 GMT
...また、httpd.conf で ServerTokens および ServerSignature コマンドを実行して、Apache のバージョンやその他の情報を非表示にすることをお勧めします (http://www.cyberciti.biz/faq/rhel-centos-hide-httpd) -バージョン/) 。

4 番目のベスト プラクティス: ロード可能な PHP モジュール (動的にロードされるモジュール) を最小限にする

PHP は「動的拡張機能」をサポートしています。デフォルトでは、RHEL はすべてのロード モジュールを /etc/php.d/ ディレクトリにロードします。モジュールを有効または無効にするには、/etc/php.d/ ディレクトリで設定ファイルを見つけて、モジュール名にコメントを追加するだけです。モジュール構成ファイルの名前を変更したり、削除したりすることもできます。 PHP のパフォーマンスとセキュリティを最適化するには、Web アプリケーションに必要なロード モジュールのみを有効にする必要があります。たとえば、gd ロード モジュールを無効にするには、次のコマンドを入力します。

# cd /etc/php.d/
# mv gd.{ini,disable}
# /sbin/service httpd restart gd という名前の php モジュールを有効にするには、次のように入力します:

# mv gd.{disable,ini}
# /sbin/service httpd restart

5 番目のベスト プラクティス: すべての PHP をログに記録するエラー

Web サイトへのすべての訪問者に PHP エラー メッセージを公開しないでください。 /etc/php.d/security.ini を編集し、次のコマンドを実行します。

display_errors=Off すべての PHP エラーをログ ファイル (http://www.cyberciti.biz/tips/) に記録してください。 php-howto-turn-on-error-log-file.html):

log_errors=On
error_log=/var/log/httpd/php_scripts_error.log 6 番目のベスト プラクティス: ファイルのアップロードは許可されません

セキュリティ上の理由から、/etc/php.d/security.ini を編集して次のコマンドを実行します:

file_uploads=Off アプリケーションのユーザーがファイルをアップロードする必要がある場合は、この機能だけを使用できます。 PHP によってアップロードできるファイルの最大サイズを制限する、upload_max_filesize (http://www.cyberciti.biz/faq/linux-unix-apache-increase-php-upload-limit/) を設定することで有効になります:

file_uploads=On# ユーザーが PHP 経由でアップロードするファイルは最大 1MB まで可能です

upload_max_filesize=1M 7 番目のベスト プラクティス: リモート コード実行をオフにする

有効にすると、allow_url_fopen が PHP のファイル関数を許可します- file_get_contents()、include ステートメント、require ステートメントなど - リモートの場所 (FTP や Web サイトなど) からデータを取得できます。

allow_url_fopen オプションを使用すると、file_get_contents()、include ステートメント、require ステートメントなどの PHP のファイル関数で、FTP または HTTP プロトコルを使用してリモートの場所からデータを取得できます。プログラマーは多くの場合、これを忘れて、入力を適切にサニタイズせずにユーザーが指定したデータをこれらの関数に渡してしまうため、コードにセキュリティ ホールが挿入されるリスクが残ります。 PHP ベースの Web アプリケーションにおけるコード インジェクションのセキュリティ脆弱性の多くは、allow_url_fopen の有効化と不適切な入力フィルタリングの組み合わせによって引き起こされます。 /etc/php.d/security.ini を編集し、次のディレクティブを実行します:

allow_url_fopen=Off セキュリティ上の理由から、allow_url_include を無効にすることもお勧めします:

allow_url_include=Off

ベスト プラクティス 8: SQL セキュリティ モードを有効にする

/etc/php.d/security.ini を編集し、次のコマンドを実行します:

sql.safe_mode=On 有効にすると、mysql_connect() と mysql_pconnect() は渡された変数を無視します。注: コードにいくつかの変更を加える必要がある場合があります。 sql.safe_mode が有効な場合、サードパーティのオープン ソース アプリケーション (WorkdPress など) およびその他のアプリケーションがまったく実行されなくなる可能性があります。また、magic_quotes_gpc (http://php.net/manual/en/security.magicquotes.php) のフィルタリングは効果的でなく、信頼性も低いため、すべての PHP 5.3.x インストールでは無効にすることをお勧めします。 mysql_escape_string() とカスタム フィルター関数はより適切に機能します (Eric Hansen のおかげで、https://www.facebook.com/EricHansen.SFU):

magic_quotes_gpc=Off 9 番目のベスト プラクティス: POST のサイズを制御するrequest

クライアント (ブラウザーまたはユーザー) がファイルのアップロードや記入済みフォームの送信など、リクエストの一部として Apache Web サーバーにデータを送信する必要がある場合、HTTP POST リクエスト メソッドに使用されます。 。攻撃者は、過度に大規模な POST リクエストを送信しようとし、システム リソースを大量に消費する可能性があります。 PHP が処理する POST リクエストの最大サイズを制限できます。 /etc/php.d/security.ini を編集し、次のコマンドを実行します。

; ここに実際の値を設定します。

post_max_size=1K1K は、PHP アプリケーションで許可される POST リクエスト データの最大サイズを設定します。 。この設定はファイルのアップロードにも影響します。大きなファイルをアップロードするには、この値が Upload_max_filesize より大きい必要があります。また、Apache Web サーバーの使用可能な方法を制限することをお勧めします。 httpd.conf を編集し、ファイル ルート ディレクトリ /var/www/html に対して次のコマンドを実行します。


,deny
## 残りの構成をここに追加できます... ##

ベスト プラクティス 10: リソース制御 (サービス拒否制御)

最大値を設定できます各 PHP スクリプトの実行時間 (秒単位)。別の推奨オプションは、各スクリプトがリクエスト データを解析するのにかかる最大時間と、スクリプトが消費するメモリの最大量を設定することです。 /etc/php.d/security.ini を編集し、次のコマンドを実行します:

# 秒単位の設定

max_execution_time = 30
max_input_time = 30
memory_limit = 40M Best実践 No. 11: PHP 用 Suhosin Advanced Protection System をインストールする

Suhosin プロジェクト Web ページ (http://www.hardened-php.net/suhosin/) から:

Suhosin は、インストールされた PHP 用の高度な保護システム。これは、PHP アプリケーションと PHP コアの既知および未知の欠陥からサーバーとユーザーを保護するように設計されています。スホシンは 2 つの独立した部分に分かれており、単独で使用することも、組み合わせて使用​​することもできます。最初の部分は、バッファ オーバーフローやフォーマット文字列のセキュリティ脆弱性を防ぐためのいくつかの下位レベルの保護手段を実装する PHP コアへの小さなパッチです。2 番目の部分は、他のすべての保護手段を実装する強力な PHP ロード モジュールです。

Linux オペレーティング システムで suhosin をインストールおよび構成する方法を参照してください (http://www.cyberciti.biz/faq/rhel-linux-install-suhosin-php-protection/)。

ベスト プラクティス 12: 危険な PHP 関数を無効にする

PHP には、間違って使用するとサーバーに侵入する可能性のある関数が多数あります。 disable_functions コマンドを使用すると、/etc/php.d/security.ini 内の一連の関数を無効にできます:

disable_functions=exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file, show_source

ベスト プラクティス 13: PHP Fastcgi/CGI - cgi.force_redirect コマンド

PHP は FastCGI と連携できます。 Fascgi は、Web サーバーが占有するメモリ リソースを削減しますが、それでも PHP 言語全体の速度と機能を提供します。ここで説明されているように、Apache2+PHP+FastCGI または CGI を構成できます。構成コマンド cgi.force_redirect は、http://www.cyberciti.biz/cgi-bin/php/hackerdir/backdoor.php などのアドレスを使用して PHP を直接呼び出すことを防ぎます。セキュリティ上の理由から、cgi.force_redirect を有効にする必要があります。 /etc/php.d/security.ini を編集し、次のコマンドを実行します:

; セキュリティ上の理由から、一般的な *Apache+PHP-CGI/FastCGI* 環境では、cgi.force_redirect

cgi.force_redirect=14 日のベスト プラクティス: PHP ユーザー ID とユーザー グループ ID

mod_fastcgi は、Apache Web サーバー用の CGI モジュールです。外部の FASTCGI サーバーに接続できます。 PHP が非 root ユーザーとして実行されていることを確認する必要があります。 PHP が root または 100 未満の UID として実行される場合、システム ファイルにアクセスしたり、システム ファイルを処理したりできます。 PHP CGI を非特権ユーザーとして実行するには、Apache の suEXEC または mod_suPHP を使用する必要があります。 suEXEC 機能を使用すると、Apache ユーザーは、Web サーバーを呼び出すユーザー ID とは異なるユーザー ID で CGI プログラムを実行できます。この例では、php-cgi は phpcgi ユーザーとして実行され、Apache は apache ユーザーとして実行されます:

# ps aux | grep php-cgi 出力例:

phpcgi 6012 0.0 0.4 225036 60140 ? S 11 月 22 日 0:12 /usr/bin/php-cgi
phpcgi 6054 0.0 0.5 229928 62820 ? S 11 月 2 日 0:11 /usr/bin/php-cgi
phpcgi 6055 0 .1 0.4 224944 53260 ? S 11 月 22 日 0:18 /usr/bin/php-cgi
phpcgi 6085 0.0 0.4 224680 56948 🎜>phpcgi 6103 0.0 0.4 224564 57956 ? S 11 月 22 日 0:11 /usr/bin /php-cgi
phpcgi 6815 0.4 0.5 228556 61220 ? S 00:52 0:19 /usr/bin/php-cgi
phpcgi 6821 0.3 0.5 228008 61252 ? S 00:55 0:12 /usr/bin/php-cgi
phpcgi 6823 0.3 0.4 225536 58536 ? S 00:57 0:13 /usr/bin/php-cgi spawn-fcgi およびその他のツールを使用して phpcgi ユーザー ID を作成し (最初に phpcgi ユーザーをシステムに追加します)、リモートとローカルを作成します。 FastCGI プロセス:

# spawn-fcgi -a 127.0.0.1 -p 9000 -u phpcgi -g phpcgi -f /usr/bin/php -cgi これで、Apache、Lighttpd、および Nginx Web サーバーを構成できるようになりました。 IP アドレス 127.0.0.1 のポート 9000 で実行されている php FastCGI を使用します。

ベスト プラクティス 15: ファイル システムへの PHP のアクセスを制限する

open_basedir コマンドは、fopen() およびその他の関数を使用して PHP がアクセスできるディレクトリを設定します。ファイルが open_basdir で定義されたパスの外にある場合、PHP はファイルを開くことを拒否します。回避策としてシンボリック リンクを使用することはできません。たとえば、/var/www/html ディレクトリのみにアクセスが許可され、/var/www、/tmp、または /etc ディレクトリへのアクセスは許可されません:

PHP プロセスが /var にアクセスするように制限します。 /www/html/ およびその他の特別に指定されたディレクトリ PHP プロセスが /var/www/html/
open_basedir="/var/www/html/" の外にあるファイルにアクセスすることを制限します。 🎜>; ----------------------------------
; 複数のディレクトリの例
; "/home/httpd/vhost/cyberciti.biz/html/:/home/httpd/vhost/nixcraft.com/html/:/home/httpd/vhost/theos.in/html/"
; ---------------------------------ベスト プラクティス No. 16: セッション パス

でのセッションのサポートPHP には、以降のアクセス時に特定のデータを保持する方法が含まれています。これにより、よりカスタマイズされたアプリケーションを開発し、Web サイトの魅力を高めることができます。このパスは /etc/php.ini ファイルで定義され、セッションに関連するすべてのデータは session.save_path オプションで指定されたディレクトリ内のファイルに保存されます。 RHEL/CentOS/Fedora Linux では、デフォルトのパスは次のとおりです。

session.save_path="/var/lib/php/session"; ファイルのアップロード時にファイルを保存するために使用される一時ディレクトリを設定します。
upload_tmp_dir="/var/lib/php/session" パスが /var/www/html の外側にあり、他のシステム ユーザーが読み書きできないことを確認してください:

# ls -Z / var/ lib/php/出力例:

drwxrwx---. root apache system_u:object_r:httpd_var_run_t:s0 session 注: ls コマンドの -Z オプションは、ファイル モジュールなどの SELinux セキュリティ コンテキストを表示します。 、ユーザー、ユーザー グループ、セキュリティ コンテキスト、ファイル名。

ベスト プラクティス 17: PHP、ソフトウェア、およびオペレーティング システムのバージョンを最新の状態に保つ

セキュリティ パッチの適用は、Linux、Apache、PHP、および MySQL サーバーの保守の重要な部分です。すべての PHP セキュリティ更新を確認し、次のツールのいずれかを使用してできるだけ早く適用する必要があります (パッケージ マネージャー経由で PHP をインストールした場合):

# yum update または

# apt -get update && apt-get upgrade Red Hat/CentOS/Fedora Linux を設定して、yum パッケージの更新通知を電子メールで送信できます。もう 1 つのオプションは、cron ジョブを介してすべてのセキュリティ更新を適用することです。 Debian/Ubuntu Linux では、apticron を使用してセキュリティ通知を送信できます。

注: php.net (http://php.net/) に頻繁にアクセスして、ソース コードからインストールされた最新バージョンを見つけてください。

ベスト プラクティス 18: ファイルとディレクトリのアクセスを制限する

Apache や www などの非 root ユーザーとして Apache を実行していることを確認してください。すべてのファイルとディレクトリは非 root ユーザー (または Apache ユーザー) が所有し、/var/www/html に配置する必要があります:

# chown -R apache:apache /var/www/html//var/ www/html/ はサブディレクトリであり、他のユーザーが変更できるファイルのルート ディレクトリです。ルート ディレクトリではファイルが実行されたり、ファイルが作成されたりすることはありません。

ファイルが /var/www/html/ の下にあり、ファイル権限が 0444 (読み取り専用) に設定されていることを確認します:

# chmod -R 0444 /var/www/html/ /var の下にあることを確認してください。/www/html/ の下では、すべてのディレクトリのアクセス許可が 0445 に設定されています:

# find /var/www/html/ -type d -print0 | どのような状況でも、Web サーバー ユーザー Apache はファイル ルート ディレクトリに書き込むことができます。注: Web サイトの開発モデルに最も合理的な権限を設定する必要があるため、必要に応じて chown および chmod コマンドを自由に調整してください。この例では、Apache サーバーはユーザー apache として実行されています。これは、httpd.conf ファイルの User コマンドと Group コマンドを使用して構成できます。 Apache ユーザーは、ファイルのルートの下にあるすべてのファイルへの読み取りアクセスが必要ですが、書き込みアクセスは必要ありません。

httpd.conf に制限的な構成を実装する次のコマンドがあることを確認してください:


オプション なし
AllowOverride なし
順序の許可、拒否
必要な場合にのみ書き込みアクセスを許可する必要があります。 WordPress やその他のアプリケーションなどの一部の Web アプリケーションでは、キャッシュ ディレクトリが必要な場合があります。次のコマンドを使用して、キャッシュ ディレクトリへの書き込みアクセスを許可できます:

# chmod a+w /var/www/html/blog/wp-content/cache
### すべてへのアクセスをブロック # ##
# echo 'deny from all' > /var/www/html/blog/wp-content/cache/.htaccess ベスト プラクティス 19: Apache、PHP、および MySQL 設定ファイルの書き込み保護

chattr コマンドを使用して設定ファイルを書き込み禁止にします:

# chattr +i /etc/php.ini
# chattr +i /etc/php.d/*
# chattr + i /etc/my.ini
# chattr +i /etc/httpd/conf/httpd.conf
# chattr +i /etc/chattr コマンドは、/var/www/html ディレクトリを書き込み保護することもできます。 php ファイルまたは複数のファイル:

# chattr +i /var/www/html/file1.php
# chattr +i /var/www/html/ 20 番目のベスト プラクティス: Linux セキュリティ読み込みモジュールを使用する ( SELinux など)

Linux には、不適切に構成されたサーバー プログラムや侵害されたサーバー プログラムを保護するために使用できるさまざまなセキュリティ パッチが付属しています。可能であれば、SELinux およびその他の Linux セキュリティ ロード モジュールを使用して、ネットワークおよびその他のプログラムに制限を課します。たとえば、SELinux は、Linux カーネルと Apache Web サーバーに多数のセキュリティ ポリシーを提供します。すべての Apache SELinux 保護変数をリストするには、次のように入力します。

# getsebool -a | grep httpd 出力例:

allow_httpd_anon_write --> off
allow_httpd_mod_auth_winbind --> _connect_cobbler - -> オフ
httpd_can_network_memcache --> オフ
httpd_dbus_avahi -- >オン
httpd_enable_cgi -->オン
httpd_enable_homedirs -->オフ
httpd_setrlimit -- > オフ
httpd_ssi_exec --> オフ
httpd_unified -->
httpd_use_gpg --> off
httpd_use_nfs --> off Apache CGI サポートを無効にするには、次のように入力します。

# setsebool -P httpd_enable_cgi off Red Hat SELinux ガイド (http://docs) を参照してください。詳細については、.redhat .com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/index.html) を参照してください。

ベスト プラクティス 21: Mod_security のインストール

ModSecurity は、Web アプリケーションを保護するオープンソースの侵入検出および防御エンジンです。 mod_security を Linux に簡単にインストールできます。インストールすると、Apache および PHP ベースのアプリケーションを XSS やその他のさまざまな攻撃から保護できます。

##いくつかの例##
#次のファイルを開くことを許可しないでください。 /etc/

SecFilter /etc/#Prevent SQL インジェクション攻撃

SecFilter "delete[[:space:]]]+from"
SecFilter "select.+from" ベスト プラクティス いいえ22: 可能な限り Apache/PHP を chroot ジェイル環境で実行します

PHP や Apache を chroot ジェイル環境に配置すると、Web サーバーを一部に隔離するため、潜在的な侵入イベントによる被害を最小限に抑えることができます。ファイルシステムの。 Apache に付属する従来の chrootjail 環境を使用できます。ただし、FreeBSD ジェイル、コンテナ概念を使用した XEN 仮想化、KVM 仮想化、または OpenVZ 仮想化を使用することをお勧めします。

ベスト プラクティス 23: ファイアウォールを使用して送信接続を制限する

攻撃者は、wget などのツールを使用して、ファイルを Web サーバーにローカルにダウンロードします。 iptables を使用すると、Apache ユーザーのアウトバウンド接続をブロックできます。 ipt_owner モジュールは、ローカルで作成されたパケットの特性をパケット作成者の特性と比較しようとします。これは OUTPUT チェーン内でのみ有効です。この例では、vivek ユーザーはポート 80 を使用して外部に接続することが許可されています (これは RHN または centos リポジトリ アクセスに機能します)。

/sbin/iptables -A OUTPUT -o eth0 -m owner --uid-owner vivek -p tcp --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT これは、Apache へのすべての発信リクエストをブロックする別の例です。ユーザーのオンサイト接続 (独自の SMTP サーバーへのアウトバウンド接続を除く)、およびスパム検証 API サービス:

# ....
/sbin/iptables --new-chain apache_user
/sbin/iptables --append OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
/sbin/iptables --append OUTPUT -m owner --uid-owner apache -j apache_user
# apache ユーザーを許可しますsmtp サーバーに接続します
/sbin/iptables --append apache_user -p tcp --syn -d 192.168.1.100 --dport 25 -j RETURN
# スパム検証のために Apache ユーザーが API サーバーに接続できるようにします
/sbin/iptables --append apache_user -p tcp --syn -d 66.135.58.62 --dport 80 -j RETURN
/sbin/iptables --append apache_user -p tcp --syn -d 66.135 。 58.61 --dport 80 -j RETURN
/sbin/iptables --append apache_user -p tcp --syn -d 72.233.69.89 --dport 80 -j RETURN
/sbin/iptables --append apache_user - p tcp --syn -d 72.233.69.88 --dport 80 -j RETURN
########################
## さらにルールを追加ここ ##
########################
# 以下は編集できません
# Apache 送信接続のすべてを削除します
/sbin/iptables --append apache_user -j REJECT ベスト プラクティス 24: ログに注意して確認する

Apache ログ ファイルを確認します:

# tail -f /var/ log/httpd/ error_log
# grep 'login.php' /var/log/httpd/error_log
# egrep -i "denied|error|warn" /var/log/httpd/error_log PHP ログ ファイルを確認します:

# tail -f /var/log/httpd/php_scripts_error.log
# grep "...etc/passwd" /var/log/httpd/php_scripts_error.log ログ ファイルを使用すると、サーバー エラーを検出できます。攻撃が何であるかを理解し、必要なセキュリティ レベルが設定されているかどうかを確認できます。システム監査のために、auditd サービスが提供されます。このサービスを有効にすると、SELinux イベント、認証イベント、ファイル変更、アカウント変更などを確認できます。 Web サーバーの監視には、標準の Linux システム監視ツール (http://www.cyberciti.biz/tips/top-linux-monitoring-tools.html) を使用することをお勧めします。

ベスト プラクティス 25: サービスをシステム インスタンスまたは仮想マシン インスタンスとして実行する

大規模なシステムがインストールされている場合は、データベース、静的コンテンツ、動的コンテンツの実行に異なるサーバーを使用することをお勧めします。



(図 1: 異なるサーバーでのサービスの実行)

異なるサーバーまたは仮想マシン インスタンスで異なるネットワーク サービスを実行します。これにより、侵害される可能性のある他のサービスの数が制限されます。たとえば、攻撃者が Apache フローなどのソフトウェアの脆弱性の悪用に成功すると、同じサーバー上で実行されている他のサービス (MySQL や電子メール サービスなど) を含むサーバー全体にアクセスできます。ただし、上記の例では、次のように異なるコンテンツが提供されます。

1. static.lan.cyberciti.biz: lighttpd または nginx サーバーを使用して、js/css/images などの静的アセットを提供します。

2. phpcgi1.lan.cyberciti.biz および phpcgi2.lan.cyberciti.biz: Apache Web サーバー、php は動的コンテンツの生成に使用されます。

3. mysql1.lan.cyberciti.biz: MySQL データベース サーバー。

4. mcache1.lan.cyberciti.biz: Memcached サーバーは、MySQL 用の非常に高速なキャッシュ システムです。 libevent または epoll (Linux ランタイム環境) を使用し、開いている接続の数に合わせて拡張でき、ノンブロッキングのネットワーク入出力を使用します。

5. LB01: nginx Web サーバーとリバース プロキシ サーバーを Apache Web サーバーの前に配置します。 インターネットからいずれかの Web サーバーへのすべての接続は、nginx プロキシ サーバーを介してルーティングされます。nginx プロキシ サーバーは、リクエスト自体を処理したり、リクエストの全体または一部をメイン Web サーバーにルーティングしたりできます。 LB01 は、シンプルな負荷分散メカニズムを提供します。
ベスト プラクティス 26: その他のツール

PHPIDS プロジェクト Web ページ (https://phpids.org/) から:

PHPIDS (PHP Intrusion Detection System) は PHP 用です。 Web アプリケーションのセキュリティ層には、使いやすさ、優れた構造、高速な操作、および高度なテクノロジという利点があります。 IDS は悪意のある入力を駆除、サニタイズ、またはフィルタリングすることはできません。単に攻撃者がサイトに侵入しようとしていることを識別し、セキュリティが必要な適切なアクションを実行するだけです。

PHPIDS を使用して悪意のあるユーザーを検出し、検出された攻撃を後で分析できるように記録できます。注: 私はこのツールを個人的に使用したことはありません。

PhpSecInfo プロジェクト Web ページ (http://phpsec.org/projects/phpsecinfo/index.html) から:

PhpSecInfo は、phpinfo() 関数に対応するメカニズムを提供して、次の情報をレポートします。 PHP 環境のセキュリティ情報と改善の提案を提供します。これは安全な開発スキルに取って代わるものではなく、いかなる種類のコードやアプリケーションのレビューも実行しませんが、多層セキュリティのアプローチでは有用なツールです。



図 2: PHP アプリケーションに関するセキュリティ情報

Linux のセキュリティ強化ポイント (http://www.cyberciti.biz/tips/linux-security.html) を参照してください。システムが直面する攻撃ベクトルの数を減らすため。

PHP バックドアに関する追加情報

PHP スクリプト、または c99、c99madshell、r57 などのいわゆる一般的なバックドアに遭遇したことがあるかもしれません。バックドア PHP スクリプトは、実際にはすべての検証メカニズムをバイパスし、必要に応じてサーバーにアクセスするために使用される隠しスクリプトです。攻撃者は、検出されないようにしながらサーバーにアクセスすることを目的としてこれをインストールします。 PHP スクリプト (またはその他の CGI スクリプト) を悪用すると、Web ブラウザのセキュリティ ホールを悪用するコードが追加されることがよくあります。攻撃者は、このセキュリティ脆弱性を悪用してバックドア シェルをアップロードし、次のようなさまざまな機能を取得することができます。 ? スパムサーバー/中継サーバーを設定しますか?
を制御しますか? すべての情報を盗みます
?情報とデータベース
?TCP/UDP ポートとその他のポートを開く

重要なポイント: PHP バックドアを見つける方法?

Unix/Linux の grep コマンドを使用して、c99 または r57 シェルを検索できます。

# grep -iR 'c99' /var/www/html/
# grep -iR 'r57' /var/www/html/
# find /var/www/html/ -name *.php -type f -print0 xargs -0 grep c99
# grep -RPn "(passthru|shell_exec |system|base64_decode|fopen|fclose|eval)" /var/www/html/ 結論

これで、PHP ベースのサーバーは適切に強化され、動的 Web ページを表示できるようになりました。ただし、セキュリティの脆弱性は主に、ベスト プラクティスと考えられているプログラミング ルールに従わないことが原因で発生します。 Web アプリケーションのセキュリティ要件を満たすには、追加のリソース、特に PHP プログラミングの知識を参照する必要がありますが、これはシステム管理者の仕事の範囲を超えています。

元のアドレス: http://www.cyberciti.biz/tips/php-security-best-practices-tutorial.html