これはどのレベルのセキュリティを提供しますか?
.htpasswdは、それ自体ではあまりセキュリティを提供しません。つまり、ログインメカニズムを提供し、Apacheは適切な資格情報がないと応答しませんが、個別に構成されていない限り、交換に関する情報は暗号化されません(または難読化されます)。たとえば、WiresharkGET
でリクエストを聞くと、クライアントから送信されているすべてのヘッダーをよく見ることができます。
Authorization: Basic d3BhbG1lcjp0ZXN0dGVzdA==
" d3BhbG1lcjp0ZXN0dGVzdA==
"は""のbase64エンコード形式にすぎませんwpalmer:testtest
。最近では、ハッカー(またはより可能性が高いのはウイルス)がパブリックWiFi接続に座って、Authorization:
後で閲覧するためにを含むすべての要求をログに記録することができます。一般に、暗号化されていないHTTP接続を介して認証情報を送信することは、有線または安全なWiFiエンドツーエンドを使用している場合でも、悪い考えと見なされます。たとえば、顧客データや支払い情報などをロックの背後に保存している場合、 PCIコンプライアンスの要件を満たしません。.htpasswd
httpsをミックスに追加すると、その特定の問題を完全に排除できますが...
.htpasswd
Apache httpdによって実装される認証は、レート制限またはブルートフォース保護の形式を提供しません。Apacheが同時ページを提供するのと同じくらい多くのパスワード推測を同時に試みることができ、Apacheは可能な限り早く成功/失敗で応答します。Fail2Banのようなものを使用して、クライアントがサーバーとの通信をブロックされる前に失敗する試行の数を制限できますが、それは必ずしもボットネットに対する有用な保護を提供するわけではありません。アドレス。これはの決定につながる可能性があります「ボットネットからのパスワードの試みに対して脆弱なままにしますか、それとも複数のクライアントからの障害のためにアカウント全体がロックダウンされたときにサービス拒否攻撃に対して脆弱なままにしますか?」
これらの攻撃の角度は、ファイルにIPベースの制限を追加して.htaccess
、特定のアドレスからの接続のみを許可することで制限できます。操作方法によっては、これは不便な場合がありますが、脆弱になる脅威の種類を大幅に制限します。あなたはまだあなたのサイトを特に標的にしている誰か、またはネットワークインフラストラクチャ自体の一部への感染の危険にさらされているでしょう。保護しているコンテンツの種類によっては、これで「十分」な場合があります。このタイプの制限の例は次のとおりです。
Order deny,allow
Deny from all
Allow from 127.0.0.1
つまり、「ローカルホストからの接続のみを許可する」ということです。行ごとに、それは意味します:
Order deny,allow
ルールが処理される順序を定義し、最後の一致が優先されます。
Deny from all
すべてのクライアントが拒否されていると想定することから始めます
Allow from 127.0.0.1
クライアントがIPを持っている場合127.0.0.1
、それは許可されます
ある程度、IPベースの制限により、HTTPSがオプションと見なされる可能性がある点まで保護されます。攻撃者/ウイルスは引き続きあなたの資格情報を見ることができますが、ページ自体でそれらの資格情報を使用することは困難です。繰り返しになりますが、これはPCIに準拠しておらず、「重要な」情報には適していませんが、これが「十分」であると見なされる場合があります。多くの人が複数のサイトで資格情報を再利用するため、サイト自体が保護されている場合でも、ログインの詳細を保護しないと、ユーザーにとって非常に危険であると一般に考えられていることに注意してください。
最後に、.htaccess
ファイル自体は少し責任があります。「パブリックディレクトリの外にある必要がありますか?」への応答を参照してください。詳細については。
簡単にバイパスできますか?
いいえ。サーバーが適切に構成されている場合、保護されたコンテンツにアクセスするためにログインの詳細を要求できないと予想する理由はありません。HTTP基本認証には欠点がありますが、Apache httpdは非常に堅牢であり、世界で最も徹底的にテストされたソフトウェアの1つです。特定のコンテンツにアクセスするにはHTTP基本認証が必要であることをApacheに通知する場合は、HTTP基本認証が必要になります。
Apacheがデフォルトで、ユーザーが2つのファイルのいずれかに直接アクセスすることを許可していない場合、それらはパブリックディレクトリの外にある必要がありますか?
これにはいくつかのポイントがあります。まず、Apacheはデフォルトでこれらのファイルのいずれかにアクセスできないようにしません。.htaccess
Apache httpdの多くのディストリビューションには、ディストリビューション、 / .htpasswd
files、.ht*
files、またはfilesに応じて、(「すべてから拒否」ルールを使用して)アクセスを防止する初期構成が含まれてい.*
ます。これは非常に一般的ですが、そうでない理由はたくさんあります。これらのファイルがまだブロックされていない場合は、これらのファイルをブロックするルールを自分で追加できます。
<FilesMatch "^.(htaccess|htpasswd)$">
Order Allow,Deny
Deny from all
</FilesMatch>
.htaccess
次に、ファイルの動作方法は、ファイルが存在するディレクトリが一致したときに処理されることを指摘しておく必要があります。つまり.htpasswd
、他の場所にある可能性があります.htaccess
が、同じディレクトリにある必要があります。とはいえ、もう少し詳細については、「速度への影響」のセクションを参照してください。
それで、それらはとても簡単にブロックできるので、なぜ.htpasswd
パブリックディレクトリの外に置いておくのですか?間違いが起こり、.htpasswd
ファイルは大きな責任を負うからです。HTTPSを使用している場合でも、.htpasswd
ファイルが公開されると、ブルートフォース攻撃によってパスワードが簡単に解読される可能性があります。最近、コンシューマーグレードのGPUは、1秒あたり数百万のパスワードを推測できます。これにより、「強力な」パスワードでさえ比較的短時間で失敗する可能性があります。繰り返しになりますが、この議論は一般的に標的型攻撃にのみ適用されますが、攻撃者が.htpasswd
ファイルを持っていてシステムにアクセスしたい場合、最近では簡単にアクセスできる可能性があるという事実が残っています。物事の状態の比較的最近(2012年4月)の概要については、コーディングホラーのスピードハッシュを参照してください。
そのことを念頭に置いて、ファイルを誤って(一時的に)公開する可能性は.htaccess
、httpdが提供するコンテンツを探しているときに決して見られるべきではない場所にファイルを移動する価値があります。はい、「パブリックディレクトリ内」ではなく「1レベル上」の場合に公開される可能性のある構成変更はまだありますが、これらの変更が誤って発生する可能性ははるかに低くなります。
速度に影響はありますか?
いくつかの。
まず、.htaccess
ファイルを使用すると、処理速度が多少低下します。より具体的には、AllowOverride all
ディレクティブは多くの潜在的な速度低下を引き起こします。これにより、Apacheは、アクセスされるすべてのディレクトリ、およびディレクトリのすべての親(までDocumentRoot
)で.htaccessファイルを検索します。これは、要求ごとにファイルシステムにファイル(またはファイルの更新)を照会することを意味します。ファイルシステムにヒットしない可能性があるという選択肢と比較すると、これはかなりの違いです。
では、なぜ.htaccess
存在するのでしょうか。それを「価値がある」ものにするかもしれない多くの理由があります:
- サーバーの負荷によっては、違いに気付かない場合があります。サーバーは本当にすべてのリクエストから最後の1ミリ秒ごとにスクイーズする必要がありますか?そうでない場合は、心配しないでください。いつものように、見積もりや予測について心配する必要はありません。実際の状況をプロファイリングし、それが違いを生むかどうかを確認します。
.htaccess
サーバーを再起動せずに変更できます。実際、これが非常に遅い原因です。Apacheは.htaccess
すべてのリクエストで変更またはファイルの存在をチェックするため、変更はすぐに適用されます。
- エラーが発生する
.htaccess
と、サーバーではなくディレクトリが停止します。これにより、ファイルを変更するよりもはるかに負担が少なくなりhttpd.conf
ます。
.htaccess
単一のディレクトリへの書き込みアクセスしかない場合でも変更できます。これにより、共有ホスティング環境に最適です。サーバーにアクセスしたり、サーバーを再起動するためにアクセスしたりする必要はありませんhttpd.conf
。
.htaccess
アクセスのルールを、それらが適用することを意図しているファイルの隣に保持できます。これにより、それらを見つけやすくなり、物事をより整理された状態に保つことができます。
.htaccess
上記のすべてを考慮しても、使用したくないですか?適用されるルールはすべて、.htaccess
直接httpd.conf
ファイルまたはインクルードファイルに追加できます。
どう.htpasswd
ですか?それはあなたが持っているユーザーの数に依存します。これはファイルベースであり、実装に関しては最低限のものです。httpd 2.2のドキュメントから:
基本認証の指定方法により、サーバーにドキュメントを要求するたびにユーザー名とパスワードを確認する必要があります。これは、同じページをリロードしている場合でも、ページ上のすべての画像(保護されたディレクトリからのものである場合)に対しても同様です。ご想像のとおり、これにより処理速度が少し遅くなります。それが物事を遅くする量は、パスワードファイルを開く必要があるため、パスワードファイルのサイズに比例し、あなたの名前に到達するまでユーザーのリストを下に移動します。また、ページが読み込まれるたびにこれを行う必要があります。
この結果、1つのパスワードファイルに入れることができるユーザーの数には実際的な制限があります。この制限は、特定のサーバーマシンのパフォーマンスによって異なりますが、数百のエントリを超えると速度が低下することが予想され、その時点で別の認証方法を検討することをお勧めします。
要するに、.htpasswd
遅いです。認証が必要なユーザーがほんの一握りの場合、気付くことはありませんが、それはさらに別の考慮事項です。
概要
で管理セクションを保護すること.htpasswd
は、すべての状況に理想的ではありません。その単純さを考えると、セキュリティとパフォーマンスが最優先事項ではない場合のリスクと問題に値する可能性があります。多くの場合、少し調整するだけで、「十分に良い」と見なすことができます。「十分に良い」とは、あなたが判断を求めることです。