メモのセット。 サイトからシステムまでのパフォーマンスと保護

短い発表



サイトの認証と登録のアカウントにいくつかの仮定を追加するつもりでしたが、睡眠不足から、または今日飲んだ多くのコーヒーから、私は荒野に引き込まれました。 いくつかのメモをスケッチしました。 あなた自身の中には何か新しいものを見つける人もいれば、誰かがあなたのために新しいルールを教えてくれるかもしれないし、誰かが私を修正してレッスンを与えてくれるかもしれません。 以下は、データベースの操作に関する注意事項です。さらに低いのは、サーバー自体の操作などに関する注意事項です。



さあ始めましょう



実際、通常、私がインターネットで見つけたほとんどすべての記事は、サイト上の登録/承認メカニズム、またはそのようなメカニズムのセキュリティについて話します。 このエントリはかなりarbitrary意的であり、サイト上の登録/承認メカニズムのロジックの主要な瞬間を含む可能性があります。



0）ユーザーanycolorによるコメント：

PHPは、crypt関数の使用を推奨しています。 md5については忘れてください。 php 5.5の登場により、パスワードを設定するための組み込み関数が既に存在するようになります。

Md5は以下で使用されていますが、代わりにcrypt（）が特別な問題になるとは思いません。

さらに、 alexkbsが示唆するように：

最新の公的にアクセス可能なハードウェア上のmd5（md5（））にソルトでキャッシュされた4桁から7桁の小さなラテン文字と数字のすべてのパスワードは、1分以内に整理できます。 リンク

ユーザーがカロンを促したように、考慮することは理にかなっています：

bcryptは、パスワード保護を保存するために設計された適応暗号化ハッシュ関数です。 フグに基づいています。 Wiki

PBKDF2（英語のパスワードベースのキー派生関数）は、パスワードベースのキー生成標準です。 ウィキ



1）パスワードを塩で保存します。

怠toのため、すべてを書き換えること、および以下の無意味さは元の投稿へのリンクですが、そこからは一部のみを取り上げます。

リンク

ハッシュパスワードの選択を回避するため（一部のインターネットサービスはこのサービスを無料および無料で提供しています）、それが側に行った場合（データベースリークなど）。



パスワードは暗号化された形式で保存されますが、各ユーザーに固有のランダムな文字をいくつか追加します（いわゆるソルト）。 さらに良いことに、塩で二重のmd5を維持します。 この方法でハッキングすることはほとんど不可能です。 userテーブルには、2つのフィールドが必要です。

1.塩を保管するための塩田。

2. md5からのハッシュを保存するためのパスワードフィールド（md5（パスワード）+ salt）。



たとえば、ユーザー認証：



// $user – user

if (md5(md5($_POST['password']).$user['salt']) == $user['password']) {

// . !

}







塩はどこで入手できますか？ 登録スクリプトで新しいユーザーごとにソルトを生成する必要があります。 これを行うには、次の機能を使用できます。



function generateSalt() {

$salt = '';

$length = rand(5,10); // ( 5 10 )

for($i=0; $i<$length; $i++) {

$salt .= chr(rand(33,126)); // ASCII-table

}

return $salt;

}







有名なエンジンのさまざまな塩漬けオプション：



md5（$ pass。$ salt）-Joomlaで使用

md5（md5（$ pass）。$ salt）-vBulletinで使用

md5（md5（$ salt）.md5（$ pass））-新しいIP.Boardで使用



この方法により、サイドでデータベースリークが発生した場合のセキュリティが大幅に向上します。



maximwによるコメント：

ハッシュの重ね合わせを使用すると、ハッシュ時間が長くなりますが、衝突の可能性も高くなります。 したがって、最初に遅いアルゴリズムを使用する方が、速いアルゴリズムを数回使用するよりも優れています。 したがって、pnp.netでは、ブローフィッシュハッシュを提供するmd5およびsha1アルゴリズムの使用を推奨していません。



PHPでソルトを生成するための素晴らしいuniqid（）関数があり、プレフィックスを使用して、保証された一意のソルトを簡単かつ迅速に取得できます。



2）パスワード推測方法も、管理者権限を取得するために本質的かつ系統的に適用されます。 ユーザー。 しかし、この方法があまり喜びをもたらさないように（多くはcaptchaを思い出して正しく行いますが、captchaが行うメカニズムに関係なく、それらをバイパス/認識するアルゴリズムなどが常に存在する傾向があります）。 ただし、パスワードの推測を非常に長くて苦痛なプロセスに変えるには、認証関数のsleep（）関数の形式の遅延をユーザーデータ検証コード自体に追加するだけで十分です。 誰かがサイクルなどを追加しますが、自転車の価値はないと思います。 個々のユーザーの約10秒は必須ではありませんが、試行するたびに+10秒延長されます。 同時に、1000回の試行はすでに10,000秒であり、ほぼ3時間になります。

ただし、この場合、承認要求の並列化を再度考慮する必要があります。 つまり、実際には、人はすぐにいくつかの承認要求をスローできるため、選択が大幅に高速化されます。 したがって、この可能性を制限する必要がありますが、1つのプロバイダーの下に座っている複数のユーザーが引き続きログインできるようにするためです。 実際、何らかの方法でログインしたばかりのIPの数をメモリに保持し、一定のタイムアウト後にそれらを削除する必要があります。 つまり、実際には、たとえば、1つのIPから15秒間の許可が3回繰り返されます。 データベースに同じIPの3つのインスタンスが存在する場合、スリープ機能で数秒間スリープ状態になり、再度ダブルチェックします。その後、「1つのIPからの認証試行回数を超えました。 数分後に試してみるか、眠りについてもう一度確認してください。 すでに意志があります。 覚えておくべき主なことは、過剰にメカニズムをオーバーロードする価値はなく、サーバーの負荷に比例して直接応答することです。 実際、サーバーのファイアウォールレベルでさらに巧妙に行動することができます。たとえば、同じiptablesが同じIPからの接続数を制限し、制限を超えてドロップする場合があります。 メモが技術的な実装よりも本質的に賢明であるという事実を考慮して、私は規則を与えません。



youloseユーザーのプロンプトとして：

スリープは間違った解決策でもあります.PHPインタープリターでアイドルスレッドを使用するだけであり、これは多くのメモリを消費しますが、これはDOS攻撃の別の手段であるため、プロキシサーバーを介してこのような保護を備えたホスティングを簡単に送信できます。 nginxの場合はlimit_req_zoneを、Apacheの場合はmod_evasiveについてお読みください。

検討する価値があります。



ユーザーが認証が遅いことを恐れないように、ユーザー自身のデータを保護するために何が起こっているかについてのメッセージを表示し、プロセスが実行中でハングしていないことを示す画像をハングアップします。



もう1つのポイントは、ユーザーの認証に失敗した後のアカウントロックアウトの実装です。おそらく誰もが既に知っていますが、忘れないでください。

amaraoユーザーが示唆したように 、この方法でアカウントを明確にブロックできます。 ほとんどの場合、IPによってブロックする必要があり、IPからブロックを解除するにはタイムアウトによってブロックする必要があります。



3）どの方法でサイトを埋めることができるかを推測することにしたので、私が思いついた次のアイデアは、上記の方法を登録に適用するというアイデアでした。登録できました。 したがって、サイトを破壊し、その命を奪うために、新しいユーザーをそのサイトから奪います。 これは以前と同様に対処します。 時間とIP登録を制限します。 いくつかのマージされたデータベースを持つファイルからリッピングされたユーザーのスクリプトをウェブサイトに登録します。 保護として、サイト上のそのようなデータベースをロールバックするには、ニックネームが登録されたIPを、たとえばLastIpフィールドで示し、確認する必要のある一意の電子メールの表示で自然に登録する方が良いです。 その後、そのような登録されたニックネームはデータベースからすばやく削除できるため、一般ユーザーが名前空間を解放できます。

maximwによるコメント：

「サイバースクワッティング」ログインを回避するには、確認メールをログインとして使用するだけで十分です。 また、確認の時間を、たとえば日数に制限します。



4）登録中にリンクを介してメールボックスを確認する瞬間を簡単にするために、指定されたメールボックスに自動生成されたパスワードを送信して、ユーザーがサイトにログインしてパスワードを自分のものに変更できるようにします。

ユーザーxnimが標準パスワードを指定したため、それ自体でパスワード自体に十分なレベルのセキュリティを既に暗示しているはずであり、パスワードのランダム化と暗号化方法を使用する必要があります。 たとえば、phpの場合：

$ pswd = substr（md5（日付（ "FY hのl dS：i：s A"）。rand（））、5.15）;





5）パスワードの回復は、最初にキーをメールボックスに送信することによってのみ行われます。その後、ユーザーはメールボックスで受信したキーを入力し、パスワードを自分のパスワードに変更するか、自動的にパスワードを生成して送信し、サイトにログオンしてパスワードを変更する必要があります。

検討する価値のあるyouloseによるコメント：

このキーが自動的に挿入されるリンクを送信する必要があります。リンクをクリックすると、すでにパスワード変更フォームがあります。 役に立たない情報をユーザーが入力しなければならないほど、サイトのユーザーは多くなります=）



6）当然、ソルトとハッシュに加えて、パスワードをクリアな形式で保存するのではなく、サイトユーザーからCookieが盗まれたかどうかを確認するチェックを実装する必要もあります。 実際、次のような特定のアルゴリズムで確認します。



if ($sess_key == md5(md5($ip).md5($uagent)) )





ユーザーのブラウザとそのIPアドレスを確認し、何かが変更された場合、セッションを破棄します。

session_destroy（）;



7）コードインジェクションまたはSQLインジェクションのユーザー入力フィールドを必ず確認してください。これには、たとえば次のようなさまざまな機能があります。

strip_tags（）

ストリップスラッシュ（）

htmlentities（）



HTMLコードの一部を残す必要がある場合、次の関数があります。



文字列strip_tags（文字列str [、文字列allowed_tags]）



この関数は、HTMLおよびPHPタグを切り取ったstr文字列を返そうとします。 不完全または偽のタグがある場合、警告とともにエラーをスローします。



また、ネットワーク上では、不要なタグを削除したり、開閉を検出したり、JSコードインジェクションを使用してXSSを試行するなどの不要な部分を削除したりするライブラリを問題なく見つけることができます。



8） GETリクエストは、本当に必要な場合にのみ使用します。 つまり、主にPOSTを使用します。主な利点は、余分なものが見えず、送信されたデータもeyes索好きな目から隠されていることです。しかし、同時にURLは見栄えがよく、ユーザーがユーザーにきれいなリンクを投げることを妨げません。 これらが唯一の利点ではありません。



9） Cookieを介したセッションIDの送信。それ以外の場合は、URLで示されます。これは、検索エンジンが好まないリンクを本質的に「台無しにします」。



10）エラーを記録することを忘れないでください。 各例外はログに記録する必要があります。これにより、後で理解すべきことや、誰かがサイトを拷問しているかどうかを確認できます。



11）データベースから必要なデータのみ。 これを行う場合：ユーザーから*を選択します。 そして、それはデータを誘惑することが判明するか、あなたはどこでもこのような習慣から書き出すでしょう、遅かれ早かれ間違いを犯し、ユーザーデータはネットワークを介して漏洩します。 第二に、データベースから取得するデータが多いほど、クエリにかかる時間が長くなり、これらすべてが負荷時のパフォーマンスに確実に影響します。 あなたは、それほど簡単ではない作業に慣れる必要がありますが、それがそうであるように、それから問題はありません。



12）検索エンジンとメタタグのサイトマップのXMLファイルの生成。 これにより、検索結果がある程度増加します。 ネットワークには、素材からメタタグを生成するための既成のアルゴリズムがあります。



13）タスクに従ってフレームワークまたはCMS / CMFを使用します。 各サイトはかなりの量の作業であり、これらの目的のための優れた基盤は、必要な他のプロジェクトへのフレームワーク（長年にわたって蓄積された）の寿命と移植性を大幅に簡素化します。 たとえば、これが単なるブログである場合、Drupal、WordPress、その他などのCMSを使用できます。タスクがよりグローバルで、エンジンの再作成がかなり難しい場合は、kohana、yii、zendなどのフレームワークを使用することをお勧めします。 このようなフレームワークには、データベースクエリコンストラクタ、キャッシュシステム（パフォーマンスにプラスの影響を与える）、ルーティングシステム、画像処理、ORM、データ検証、および作成者またはコミュニティが開発した追加モジュールを接続する機能が既に含まれています。 これにより、デバッグされたコードとパフォーマンスへの十分な注意により、開発とデバッグの時間が大幅に短縮されます。



14） imgタグ内の画像に高さと幅の属性を使用する代わりに、読み込み時に異なるパラメーターで複数の画像サンプルを保存することをお勧めします。たとえば、full_img.png（full）、preview_img.png（小さなコピー）、大きな画像（ページの読み込み速度とチャネル占有率を低下させる）が必要であり、ブラウザはそれをスケーリングする必要がなく、ページの表示速度に影響します。



15）データベースのフィールドのインデックス付け。 インデックス付きフィールドを作成すると、データベースとサイト全体のパフォーマンスに大きく影響します。 多数のリクエストがある場合、これはサーバーの負荷を大幅に削減し、コストを削減します。

anycolor ：

フィールドを賢くインデックス付けする必要があります。そうしないと、多くの問題を自分自身に追加することができます。 すべてのインデックスが良い結果をもたらすわけではありません。 まず、遅いクエリのプロファイルを作成し、EXPLAINを監視する必要があります。その後、キーの作成と決定について決定します。



16）データとクエリの両方のキャッシュを使用します。 たとえば、kohana 3では、-> cached（30）を追加してデータベースクエリをキャッシュできます。クエリを作成すると、クエリが30秒間キャッシュされ、ファイルキャッシュ、memcached、sqliteなどの選択によりキャッシュされたデータ全体が保存されます。 。 ただし、キャッシュでは、データが古くなっている可能性があるため、中盤に固執する必要があることを忘れないでください。たとえば、ユーザーが記事を調整したため、この場合、ユーザーが古いデータを提供しないようにこの保存されたキャッシュ値をリセットする必要があります。 彼は確かにそのような反応を理解しないでしょう。



17）専用サーバーがある場合は、nginxをフロントエンドとして使用し、apache2（または代替）をバックエンドとして使用して、負荷を共有します。 これについては、ネット上で多くのことが書かれています。



18）オペコードをキャッシュするためにxcache / eaccelerator / otherを使用します。これはいくつかの点でパフォーマンスに影響します。



19）基本的なルールの1つは、データベースの正規化と設計は単なる言葉ではないということです。 これは一種の科学であり、専門的にこれを行う人々の黄金律です。 データベース上にWebサイトを作成しないでください。1つのテーブルには、たとえば80のフィールドがあります。 これは、最初はデッドサイトと見なすことができます。 データをテーブルに論理的にパーティション分割し、キーを使用し、残りの正規化ルール（もちろん、これに合わせないでください）は、パフォーマンスに最も直接的な影響を与える必要があります。

maximwによるコメント：

現在、Web開発では、クエリを高速化するためにデータベースの非正規化が非常に重要です。 これについて言及しておくといいでしょう。

非正規化はユーザーJuliaTem によってこの投稿で説明され ました



20）管理の最も重要なルールの1つは、次のようなものです。「最初にすべてを禁止し、次に必要なものだけを許可する」。 多くの人にとって「すべてを許可してから禁止」するのは簡単ですが、このアプローチでは間違いなく何かを忘れてしまい、サイトのセキュリティが著しく損なわれます。



21）クエリでJOINを使用する方が、いくつかの個別のクエリよりも優れています。 JOIN演算子について十分に理解している場合、残りを説明するのは無意味だと思います。 データベースへのクエリが少ないほど、サイトは高速になり、サーバー/ホスティングの負荷が少なくなります。 さらに、JOIN演算子を使用したクエリの結合は、インデックス付きフィールドで実行する必要があります。

ユーザーmaximwからの説明 ：

JOINについて物議を醸す声明。 特定の状況に大きく依存します。 たとえば、2つの連続したSELECTが高速になります。

簡単に言えば、適切なツールを適切な場所で使用する必要があります。 =）



22）データベースのデータ整合性。 ユーザーを削除しないようにデータベース内のデータを常に監視する必要がありますが、ユーザーの記事を削除したり、コメントを削除せずに記事自体を削除したりしないでください。 したがって、ベースが拡大し、その中にゴミが蓄積されます。これは、論理チェーン全体を一度に計算するよりも追跡とクリーニングが困難です。



23）データは断片化されており、パフォーマンスに影響するため、データベース内の同じデータを時々最適化する必要があります。 MySQLでは、このために必要なものはすべてすでに提供されています。

FAQへのリンク 。



Q. MySQLでストレージを最適化する方法は？

ホールの消去（デフラグ）、統計の更新、およびインデックスのソート：



OPTIMIZE TABLE table_name;

または使用：myisamchk --quick --check-only-changed --sort-index --analyze

注意、myisdが起動しないときにmyisamchkを起動する必要があります。そうでない場合は、mysqlcheckユーティリティを使用する必要があります。

（mysqlcheck --repair --analyze --optimize --all-databases --auto-repair）



オプティマイザー統計の更新：

ANALYZE TABLE table_name;

または使用：myisamchk --analyze



定期的に実行することをお勧めします。

isamchk -r --silent --sort-index -O sort_buffer_size = 16M db_dir / *。ISM

myisamchk -r --silent --sort-index -O sort_buffer_size = 16M db_dir / *。MYI





24）遅いクエリを追跡し、可能な限り最適化を試みます。

mysql構成（my.cnf）で、次の2行を記述する必要があります。



log_slow_queries = /var/log/mysql/mysql-slow.log

long_query_time = 1



説明する：

log_slow_queries-保存するファイル

long_query_time-すでに誓約するのに十分だと思われるクエリ実行時間。 秒数。



25）さまざまなオプションを検討します...技術的な詳細ではない可能性が高いですが、...現在、SQLとNoSQLの両方の多くのDBMS、フレームワーク、ライブラリなどがあります。 これはすべて、設計段階で検討することが非常に望ましいことです。 プロジェクトが強力なものに成長した場合、間違いはすべて確実に発生します。 mysqlで同じデータベースエンジンを使用しても、両方の利点を考慮するのに十分な数のエンジンを使用します。 MariaDBを例にとると... PostgreSQL。 , … ? ? , . , … , , SQL , NoSQL .



26) . . , MySQL Apache2 Nginx. - .



27) frontend-. - . nginx . . .



28) , , , , . . , . Ext2/3/4, ReiserFS, FAT, NTFS, .



29) , /. , , , . sysctl (- Linux, BSD, ) . :



sysctl -a

:

sysctl net.ipv4.ip_forward=1

:

/etc/rc.local



, .

, .



/.

Nixのようなシステムにはそれらのいくつかがあります。ユーザーシステム用に設計されたものや、サーバー用に設計されたものなどがあります。実際には、それらに関する十分な情報もあります。例えば、次のとおりです。Scheduler

IO



30）プロセスを起動/監視するためのシステムとしてのSystemd。この段落では、私はデーモンが本当に好きだったので広告の可能性が高く、Debianではデフォルトでは価値がありませんが、置くことは問題ではありません。 SystemD自体を参照して説明しました。ここで



は、SystemDの利点を簡単に説明します。Systemdbuns



：

— , , . required, , , , , SysV, , .



- , systemd, . , :



— SysV , grep, find . systemd , .

— SysV sh-, systemd.

— ! cgroups . , , . .

— ! systemd . ! monit pid, ! , , .

— Systemd .

— systemd //_-_ .

— ! .., SysV, fstab /etc/init.d/-_ start/stop

— D-Bus.





31) . . . Gentoo . . Debian apt-build, , . make, . , , /, //_ , . , , . .



32) . , , . , ssh, . , fail2ban ssh , , iptables, host.deny IP . . Portsentry , , . chkrootkit — . iptables, . PHP .



PS .

PPS , .