web-dev-qa-db-ja.com

LAMPサーバーを保護するためのヒント

これは 標準的な質問 LAMPスタックの保護についてです

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

96
Aditya Shukla

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

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

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

A
Apacheはセキュリティで保護するのが楽しい場合があります。私は、ApacheやPHPよりOSを強化して使いやすさを維持する方が簡単だと思います。

M

P
これは、独自の規律であるセキュアプログラミングプラクティスの全体的なアイデアに真っ向からぶつかります。 SANSとOWASPには、この件に関する馬鹿げた情報が含まれているので、ここでは再現しません。ランタイム構成に焦点を当て、残りは開発者に任せます。 LAMPの「P」はPerlを指す場合もありますが、通常はPHPを指します。私は後者を想定しています。

108
Scott Pack

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

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

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

14
David

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

ファイアウォール

  • 素敵なアプローチは、トラフィックの開始を許可せず、必要に応じて必要なものだけを開くです。これにより、物事を機能させるために最小限のポート/ IPが開かれ、公開が最小限に抑えられます。
  • LAMPサーバーの場合、http/httpsのポートを世界に開放し、sysshの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 authenticationは脆弱なCMSの前に位置し、アクセスをブロックするのに役立ちます。これは攻撃を防ぐための良い方法です)
  • SSLを使用管理領域およびその他の機密データ用
  • サーバーとインフラストラクチャの管理を自動化します(Puppet、Chef、SaltStackなどの何か。AWSCloudFormationも使用している場合)。これにより、多数のサーバーにパッチを適用し、サーバーAでの権限の修正などのシナリオを削減できますが、サーバーBでの実行を忘れます。
  • PHPまたはWebServer)の特定のバージョンのCMSを可能な限り提供しないでください。この情報を不明瞭にすることはセキュリティではありませんが、さまざまなソフトウェアの特定のバージョンや攻撃者が働かなければならないほど、自由に提供できる情報が少なくなります。これは、あなたがぶら下がっている果物の1つではないことを確認するための良い方法です。もちろん、これは、もう少し努力して、に
  • サーバーにアクセスできる人を制限する
9
Drew Khoury

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

これが意味すること:ApacheユーザーまたはMySqlユーザーのいずれかが危険にさらされた場合、Apacheがアクセスできるフォルダーの範囲外(Apacheユーザーの場合)とテーブルの外で害を及ぼすことはできません( s)/ database(s)(MySQLデータベースのユーザーの場合)。

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

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

時間例!アイデアを簡単にするためのシステム例を紹介します。

システムにユーザーがいるとします(rootはumod -lやpasswd -lなどのセキュリティを確保するために無効にする必要があります):john、barney、terence、Lisa。

mySQLでbigbirdという名前のユーザーを作成できます(必ずハッシュ化パスワードを使用してください)。 Bigbirdには選択権限と更新権限しかありませんが、ドロップや作成はできませんさらに、MySQLデータベースで作業するためにgarfieldという名前の別の管理MySQLユーザーを作成し、rootユーザーを削除しますMySQLデータベースから変更して、妥協できないようにします。 garfieldには、MySQL全体で特権が付与されています(事実上、これはルートの名前を変更するだけです)。

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

また、sshアクセスを特定のユーザーのみ(または特定のグループ、sshグループに入れて、sshを使用できる唯一のものにする)に制限することもできます。

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

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

5
86bornprgmr

SANS.orgからのこのドキュメントは本当に役に立ちました http://www.sans.org/score/checklists/linuxchecklist.pdf

3
wsindhu

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

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

1
Quarind