これは、LAMPスタックの保護に関する標準的な質問です

LAMPサーバーを保護するための絶対的なガイドラインは何ですか？

Davidの答えは、サーバー強化の一般原則の優れたベースラインです。デビッドが示したように、これは大きな質問です。採用する特定の手法は、環境とサーバーの使用方法に大きく依存します。警告、これはテスト環境で構築して適切に実行するために多くの作業を要する場合があります。その後、実稼働環境、さらに重要なことにはビジネスプロセスに統合するための多くの作業が続きます。

ただし、最初に、組織に強化ポリシーがあるかどうかを確認します。これらのポリシーは最も直接的に関連している可能性があります。そうでない場合、あなたの役割にもよりますが、これはそれらを構築する絶好の機会かもしれません。また、各コンポーネントをボトムアップで個別に取り組むことをお勧めします。

L
あなたを助けるために利用可能な多くの良いガイドがあります。このリストは、ディストリビューションによっては役立つ場合とできない場合があります。

• Center for Internet Security Benchmarks-主要なフレーバーに固有の配布
• CentOS Hardening HowTo -CIS RHEL5ガイドに従いますが、はるかに読みやすい
• NIST SP800-123-一般的なサーバーセキュリティのガイド
• NSA Hardening Factsheets -CISほど更新されていませんが、依然としてほとんど適用可能
• Tiger-ライブシステムセキュリティ監査ソフトウェア

A
Apacheは保護するのが楽しい場合があります。ApacheやPHPよりもOSを強化して使いやすさを維持する方が簡単だと思います。

• Apache Server Hardening -ITセキュリティの姉妹サイトに関するこの質問には、多くの有益な情報があります。
• Center for Internet Security Benchmarks-再び、Apacheベンチマーク。
• Apacheセキュリティのヒント -Apacheプロジェクトから直接、基本をカバーしているように見えます
• DISA強化チェックリスト -DoD Information Assuranceのチェックリスト

M

• Center for Internet Security Benchmarks-繰り返しますが、MySQLベンチマーク用
• OWASP MySQLの強化
• 一般的なセキュリティガイドライン -プロジェクト開発者による基本的なチェックリスト

P
これは、セキュアプログラミングプラクティスの考え方全体に真っ向から取り組みます。SANSとOWASPには、この件に関するとてつもない量の情報があるため、ここでそれを再現しようとはしません。ランタイム構成に焦点を当て、開発者に残りを心配させます。LAMPの「P」はPerlを指すこともありますが、通常はPHPを指します。私は後者を想定しています。

• PHPの強化-ITセキュリティSEサイトでもいくつかのマイナーな議論。
• Hardened PHP Project - Suhosinを生成するメインプロジェクト。特定のタイプの攻撃に対してプロジェクトするようにPHPアプリケーションにパッチを当てます。
• SuhosinによるPHPの強化-Suhosin専用の簡単なHowTo
• php.iniからPHPを強化-短いが、セキュリティ関連のランタイムオプションのいくつかに関する悪い議論

率直に言って、このトピックに関する数冊の本に値する質問をしました。しかし、うまく機能する一般的な基本的なガイドラインがいくつかあります。

1. 更新してください。これは、実行しているOS、すべてのサービス、特にすべてのWebアプリケーションを意味します。
2. 不要なサービスを無効にし、必要なサービスを最小限の露出に制限し（MySQLにリモート接続していない場合、TCPでリッスンしないようにします）、ホストベースのファイアウォールを実行します。（厳密にLAMPの場合は、80と443で十分ですが、管理用にもSSHが必要な場合があります。）
3. 強力なパスワードを使用してください。さらに良いことに、SSHを使用する場合は、キーベースの認証のみを使用します。
4. ルートとしてログインしていないことを確認してください。ユーザーとしてログインし、suおよびsudoを使用します。
5. 安全性を高めることはできませんが、サーバーで何が起きているかを把握するために、logwatchなどのツールを実行する必要があります。

それがあなたが始めるのに役立つことを願っています。

ここに私が始めたいと思う良いチェックリストがあります。

ファイアウォール

• 良い方法は、最初からトラフィックを許可せず、必要なときに必要なものだけを開くことです。これにより、最小限のポート/ IPが開かれ、動作するようになり、露出が最小限に抑えられます。
• LAMPサーバーの場合、世界へのhttp / httpsのポートとsysadminのsshのみを開く必要があります。
• ipv6トラフィックなどを使用しない場合はロックダウンしてください
• AWSにはセキュリティグループがあり、Linuxにはiptablesと豊富なパッケージがあります。

SSHとユーザー

• SSHアクセス用のパスワードなし（秘密鍵を使用）
• rootがsshを許可しないようにします（適切なユーザーはsshを実行してから、suまたはsudoを実行する必要があります）
• ユーザーにsudoを使用して、コマンドがログに記録されるようにします
• 不正なログイン試行をログに記録します（また、fail2banなど、サーバーに何度もアクセスしようとするユーザーをブロック/禁止するソフトウェアを検討してください）
• 非標準ポートでのssh（これは、ぶら下がっている果物ではないことを確認し、迷惑なトラフィックの多くを遠ざけるのに役立ちますが、特にそれ自体ではセキュリティにはあまり役立ちません）
• sshを必要なIP範囲のみにロックダウンします（大きな範囲は、範囲なしよりも優れています）

データベース

• ユーザーデータのサニタイズ
• クエリのパラメーター化
• DBを独自のマシンに抽象化することを検討してください。この分離により、攻撃者がWebスタックにアクセスするのがより困難になる可能性があります。
• ソフトウェアを最新の状態に保つことが重要です。
• 各目的のユーザー。ユーザーを作成する場合、権限なしで開始し、ロールを実行するために必要なユーザーのみを追加します。異なるアプリケーション（またはアプリケーションの異なる部分）に別々のユーザーを設定すると、攻撃者が1つのアカウントを侵害した場合の利点を減らすのに役立ちます。また、GRANTのような特別な特権には注意してください。
• パスワードを定期的に変更するポリシーを作成することをお勧めします。必要な労力が心配な場合は、頻度が少ないほど良いことを覚えておいてください。
• パスワードの暗号化を理解する。ソルトパスワード。md5を使用しないでください！

ソフトウェア

• ソフトウェアを最新の状態に保ちます（OS、Webサーバー、スクリプト言語、CMS）。そこにいる多くの人々が古い（パッチを当てていない）バージョンの既知の脆弱性をスキャンします
• 不要なソフトウェアを削除します（運用サーバーでソフトウェアをコンパイルするために必要なパッケージを保持しないことが理想的です。ソフトウェアをプリコンパイルして、運用マシンでパッケージとして利用できるようにすることをお勧めします）
• ファイルのアクセス許可がロックダウンされていることを確認してください（特にユーザーのアップロードや構成ファイルなど）
• WebサーバーレベルでのCMSのパスワード保護管理領域（http認証は脆弱性CMSの前に位置し、アクセスをブロックするのに役立ちます。これは攻撃を防ぐ良い方法です）
• 管理領域およびその他の機密データにSSLを使用する
• サーバーとインフラストラクチャの管理を自動化します（Puppet、Chef、SaltStackなど。AWSCloudFormationも使用している場合）。これにより、多くのサーバーにパッチを適用し、サーバーAで権限を修正するがサーバーBでそれを行うのを忘れるなどのシナリオを削減できます。
• 可能であれば、CMS、PHP、またはWebServerの特定のバージョンを公開しないでください。この情報を不明瞭にすることはセキュリティではありませんが、さまざまなソフトウェアの特定のバージョンをスキャンする人が多く、自由に提供できる情報が少ないほど、攻撃者は仕事をしなければなりません。これは、ぶら下がり果物の1つではないことを確認する良い方法です。もちろん、これは、もう少し手間をかけたい人には何もしません
• サーバーにアクセスできる人を制限する

Davidの提案に加えて、インストールのモジュール化が進むと、1つのタスク専用に作成された特定のユーザー/グループへのアクセスを制限し、スコープを制限することになるため、LAMPスタックの安全性が高まります。これは、Apacheユーザーの例です重要なシステムファイル/フォルダにアクセスできるグループではなく、それに応じて権限が設定されたApacheファイル/フォルダの場合。提供するWebサイトに関連付けられているMySqlテーブルにアクセスできるユーザー。これらのテーブルのみ。さらに、PHP呼び出しから最小限のアクセスを許可するようにアクセスを制限できます。また、PHPファイルで使用/公開されるMySQLユーザー名が、別のユーザーに使用されるユーザー名またはパスワードと同じではないことを確認してください。

これが意味すること：apacheユーザーまたはMySqlユーザーのいずれかが危険にさらされた場合、apacheがアクセスできるフォルダーの範囲外（apacheユーザーの場合）およびテーブルの外部（ s）/ database（s）（MySQLデータベースのユーザーの場合）。

MySQLユーザーが何らかの理由で侵害された場合、たとえば、データベースにアクセスしてMySQLからすべてのデータベースを削除し、すべてのデータを破壊することはできません。状況によっては、隔離されたデータベースのテーブルを削除したり、一部のテーブルに情報を挿入したりする可能性があるため、絶対に必要な場合にのみテーブルアクセスを許可し、必要な権限のみを許可することが重要です。テーブルの削除特権または更新特権が必要な場合は、そのユーザーに付与しないでください。

また、何らかの理由でMySQLの管理アカウントのユーザー名とパスワードが見つかった場合、システム上のユーザー名とは異なるユーザー名を使用すると、データベースにアクセスして損害を与える前に、まずシステムのセキュリティを破る必要があります。Apacheユーザーとファイルへのアクセスについても同じことが言えます。

例の時間！システムの例を挙げて、アイデアを単純化します。

システムにユーザーがいると言います（セキュリティのためにumod -lやpasswd -lなどを使用してルートを無効にする必要があります）：john、barney、terence、lisa

MySQLでbigbirdという名前のユーザーを作成できます（ハッシュ化されたパスワードを使用してください）。Bigbirdには選択権限と更新権限のみがありますが、削除や作成はできません。 さらに、MySQLデータベースで作業するためにgarfieldという名前の別の管理MySQLユーザーを作成し、MySQLデータベースからrootユーザーを削除して、そのユーザーが侵害されないようにします。ガーフィールドは認められました。MySQL全体の特権（事実上、これはルートの名前を変更するだけです）。

ここで、Apacheグループまたはユーザーのいずれかを作成し、apweb2と呼びます。Appweb2は他のグループのメンバーではなく、Apacheのすべてのファイル/フォルダーは/ home / apweb2 /に保存されます。各仮想ホストには独自のサブフォルダーがあり、これらの各ホストには、そのサブフォルダーに設定されたドキュメントルートがあります。システムの残りの部分へのアクセスを誤って提供しないために、シンボリックリンクは無効になります。

また、特定のユーザー（または特定のグループ、私はそれらをsshグループに入れて、それだけでsshを使用できるようにする）のみにsshアクセスを制限できます。

また、sudo特権を持つユーザーを選択して、さらに制限することもできます。さらに進めることができる別のステップは、sshを使用できないsshユーザーを作成することです。sshを使用できないsudoを使用できる特別なユーザーを作成できます。したがって、sshしたら、別のユーザーにログインしてもらう必要があります。 sudoへのアクセス。

そのため、各セグメントをモジュール化することで、セグメントが危険にさらされても、スタック全体が危険にさらされることはなく、最初から最初からやり直す代わりに1つの問題を解決できます。

SANS.orgのこのドキュメントは非常に役立つことがわかりましたhttp://www.sans.org/score/checklists/linuxchecklist.pdf

現時点では、コンテナの仮想化、つまりDocker、systemd-nspawn、およびコンテナの仮想化のメカニズム（名前空間、cgroup）を無視しないでください。コンテナ仮想化を使用すると、プロセスの分離が可能になります。たとえば、サービスの1つが侵害されても、攻撃者は他のサービスにアクセスできません。

LAMPの場合、たとえば、SSHサーバー、Apache、MySQL、PHP-FPM / Python / Perl / etcで4つのDockerコンテナを使用できます。