セッション数を制限するには？
Webセッションを追跡してWebアプリに制限する方法が必要です。 「セッション」は、上記のWebアプリのページを閲覧する単一のユーザーとして大まかに定義されます。次のように翻訳できます。
- セッションはタプル
<clientIP,vHost>として定義されるか、レイヤーと利用可能なデータに応じて、<clientIP,serverIP,serverPort>または<cookie,vHost>として定義されます。 - ユーザーが認証データを定義済みのログインURIに送信した後にセッションが開始します
- ユーザーが定義されたログアウトURIに到達すると、セッションが終了します
- クライアントが最後のオブジェクトを要求した後、指定されたタイムアウトの期限が切れた場合、セッションは終了します
指定されたセッション制限に達した後、次のユーザーはカスタムエラーページにリダイレクトされます。また、監視目的で現在のセッション数を追跡する方法と、監視サーバー（webappにクエリを定期的に発行している）をホワイトリストに登録して制限から除外する機能も必要です。
私が扱えるもの：
- RadWare AppDirector Webアプリケーションには独自のファームが定義されており、リバースプロキシモードで実行されています
- Apache 2.2
- SLES 11 SP2
他のオプションが残っていない場合は考慮しますが、追加のプロキシサーバーを使用しないことをお勧めします。
これらすべての背後にある理論的根拠は、前述のWebアプリが簡単に過負荷になり、リクエストを不規則に拒否し始め、プロセスで（通常）フォームエントリデータを失う作業中のユーザーを怒らせます。過負荷状態になる可能性が低い制限を指定することで、負荷が急上昇する可能性が高い場合にユーザーが後で戻るように指示される、明確に定義された障害状態を作成したいと考えています。
Edit：Webアプリは3層の実装で、最初の層（プレゼンテーションレイヤー、実装） Apache vHostのCGIコードとして）はかなり単純化されており、アプリケーションサーバー間の基本的なエラー処理とリクエストのロードバランシングに限定されているようです。それが実行されるWebサーバーに大きな負荷をかけることはありません。これが、AppDirectorファームで単なるフェイルオーバーモード（負荷分散なし）で実行している理由です。
この時点以降のすべては基本的にブラックボックスです。データ層にはMSSQLデータベースがありますが、テーブル構造に関する意味のある情報をベンダーから入手することはほぼ不可能です。アプリケーションサーバーはクローズドソースであり、ベンダーは実装にかなり包括的なフレームワークを使用していますが、操作に関連するそれほど複雑でない質問には答えられないようです。
あなたが最終的に解決しようとしている問題は、アプリケーションの能力にあります-そしてそれがあなたが問題を解決するべき場所です。あなたが言及しているコンポーネントは、HTTPアプリケーションのセッション管理とは何の関係もありません。
Iptablesの最近のモジュールで適用できるいくつかのトリックがあります。または、意図された目的とは逆の方法でfail2banを使用します。ただし、これらの両方には、ツールと問題ドメインの非常に詳細な理解が必要です。これらのコンポーネントのレベルでアクセス制御を実装できますが、セッション数に関するアプリケーションからの公開された状態情報によって駆動します。
監視目的で現在のセッション数を追跡する方法も必要です
とりあえず、アプリケーションがブラックボックスでありスコープなしの場合、変更/インストルメンテーション（ほとんどあり得ない）であると想定すると、この情報を取得できます。 Apacheのログから、セッションCookieを含めて（アクティブなCookieのリストを維持するようにログをフィルタリングまたはテールし）、ログアウトURLと一致するか、TTLに対応していないエントリをリストから削除します。
これは正確にはあなたが求めているものではありませんが、私はF5ロードバランサーで次のことをすでに行っています。
- ログインページで投稿リクエストの数をカウントします。
- 1秒あたりのログイン数が最初の制限を超えている場合、ユーザーを遅らせます
- 1秒あたりのログイン数が2番目の制限を超えている場合、ユーザーをメンテナンスページに移動する
ウェブサイトは時々重い負荷（競馬）を受けていたので、それは助けになりました。
この問題は、RadWare AppDirectorを使用することで解決できます。また、（完全にするために）以下のコメントの優れた結果に従って、Apache mod_securityを使用することで解決できる可能性があります。
AppDirectorソリューションの場合、同じバックエンドサーバーにマッピングする2つのファームを作成できると思います。これらのファームには、さまざまな基準と運用条件を適用できます。 1つのファームは「デフォルト」になり、もう1つは「セッション」として定義したURIに応答します。後者は、ロードバランサーで受け入れるセッションの量に制限があります。
これからは、次の2つの理由から、「ログイン」を「セッション」に置き換えます。
- ユーザーが認証されるという望ましい状態を明確に定義するため、あいまいさを回避できます。
- AppDirectorユーザーガイドとGUIは、「接続」という用語を再定義して、すべての実用的な目的で「セッション」と同じ意味を持つようにしています。以下を参照してください。これにより、混乱を避けることができます。
「ログインした」ファームが選択した接続制限に達した場合に、申し訳ありませんページを表示することも可能です。
方法を説明する前に、AppDirector製品の操作経験がないことを明確に述べる必要がありますが、競合するわずかに高度ではないロードバランサーを毎日管理します。私が使用する製品は、このシナリオをすぐに実行できます。 AppDirectorユーザーガイドと、AppDirectorについても同様であることを示唆しているオンラインドキュメントの情報を見つけました。ただし、概念は似ていますが、用語は異なります。私は文言に関してローマ時代の行動をしているだけであり、あまりにも明らかに無知なバカにならないようにそれをかなり正しくすることを望んでいます。
最大の障害はマニュアルへのアクセスを得ることでした。マニュアルは、アクティブな顧客でない限り利用できません。いくつかグーグルすることで、古すぎない古いバージョンを見つけることができました。また、ナレッジベースの記事とこのリンク Radware AppDirector – Configuration：Basic Application も見つけました。
以下は、主にユーザーガイドで解釈されるソリューションドラフトです。
ロードバランサーへのクライアントエントリは、「デフォルト」セッションと「ログインセッション」の両方を接続するために使用されるVIPを通じて行われます。これは、pによるL4ポリシーを通じて実現されます。ユーザーガイドの99：
"When AppDirector receives the first packet of a session destined to a
Virtual IP address, it searches for a Layer 4 Policy that matches the
Layer 4 Protocol, Destination port, Source IP, etc. Then, based on this
information, AppDirector selects the farm allocated to this service and
the best server for the task from that farm, and forwards the packet to
that server.
L4ポリシーは、適切なファームを選択するために使用されるL7ポリシーに関連付けることができます。 L7ポリシープロセスについては、ユーザーガイドp.104で説明しています。
"The Layer 7 content aware decision making mechanism allows you to have
a single point of entry to the site, and provides differentiated service
for different user groups.
A Layer 7 decision is made using a mechanism called Delayed Binding.
When Delayed Binding is used, AppDirector first performs a TCP handshake
with the client to receive the HTTP request. AppDirector parses the HTTP
request’s data, usually HTTP headers, and performs the load balancing
decision. Only after that, does AppDirector select a farm and a server.
Lastly, AppDirector initiates a TCP handshake with the server and
forwards the traffic to it
[...]
When Layer 7 Policies are used, farm selection is based on matching the
request data with a list of Layer 7 Policies defining the Layer 7
parameters differentiating the service. The process of server selection
within the farm can also be content-based, using a third Layer 7
parameter."
L7の動作を定義するために使用できる方法については、p.106で説明しています。これらのうち、適切な方法を選択して、「デフォルト」のファームではなく「ログインした」ファームへのルーティングを選択できます。
"Methods are the basic building blocks for Layer 7 service selection.
They define content by which traffic is differentiated. You can use
the same Method to select one or more services. The following Method
Types are available:
- URL: Looks for a specified Host name and/or path in the HTTP request.
- File Type: Looks for a specified File Type in the HTTP request.
- Header Field: Looks for a specified Header Field in the HTTP request.
- Cookie: Looks for a specified Cookie in the HTTP request.
- Regular Expression: Looks for a regular expression anywhere in the
HTTP request. AppDirector supports Posix 1002.3 regular expressions;
the string can be up to 80 characters.
- Text: Looks for a text string anywhere in the HTTP request."
Basic Application リンクに示されているように、たとえば、別のファームにルーティングするためのURIパターンを評価するL7ポリシーを作成できます。作成されたURIパターン '^/login？= true'および '^/loggedin'は、「ログインした」ファームにルーティングできます。構成されたパターン '^/logout'（および他のすべてのURI）は、同様に「デフォルト」のファームにルーティングできます。
ファームはユーザーガイドp.121によって次のように定義されます。 "AppDirectorファームは、同じサービスを提供するネットワークサーバーのグループです[...]複数のサービスを提供するサーバーは、複数のファームで使用されています。」
サーバーは、バックエンドサーバーの定義を2つのレイヤーに分割することでさらに区別されます。「物理サーバー」オブジェクトレイヤーはサーバーのIPアドレスを表し、「ファームサーバー」オブジェクトレイヤーは1つ以上の物理サーバーで実行されているサービスを表します。
ファームでのセッション制限は、「AppDirectorユーザーガイド」に従って、物理サーバーオブジェクトごとに加えて、ファームに定義された各ファームサーバーオブジェクトごとに（および他の方法で）実行できます。これは、p.137の他の場所で説明されています。
"The Connection Limit is the maximum number of users that can be directed
to a server for a service provided by the farm. The number of users allowed
depends on the Sessions mode selected because it determines the number of
active entries in the Client Table for sessions destined to the specific server.
When the Entry Per Session or Server Per Session modes are selected, the number
of active entries destined to the same server is higher than in the Regular
mode (see Regular, page 153).
When the Regular mode is selected, all requests from a single client IP destined
to the same server are reflected by a single entry in the Client Table (see
Client Table Views, page 164).
The default value for the Connection Limit parameter is 0. When it is configured
to 0, it is disabled for this server and there is no user number limit."
クライアントテーブルとその「通常モード」はp.153で定義されています。
"The Layer 3 Client Table is always used when Entry Per Session is used.
AppDirector uses the Layer 3 Client Table to ensure Layer 3 persistency.
This table contains information about the server selected for each client
(Source IP address) in each farm, and it allows AppDirector to select a
server for a new session.
[...]
In the Regular mode, AppDirector maintains Layer 3 persistency. In this mode,
each entry is identified by the following parameters:
• Layer 4 Policy VIP Address
• Client IP Address
• Destination TCP/UDP Port Used from the Client to the Server"
Basic Application ページのサーバー定義ウィンドウのスクリーンショットでは、サーバー接続制限ボックスが帯域幅制限ボックスのすぐ横に表示されています。
したがって、構成によって多少異なりますが、この回答の目的では、クライアントテーブルを介して定義された「接続」と、ユーザーが定義した「セッション」は基本的に同じものになります。そして、その効果に対する制限は、ファーム内のサーバーオブジェクトごとに課すことができます。
AppDirectorは物理サーバーとファームサーバーを区別するため、Apache物理サーバーオブジェクトにマッピングする2つのファームサーバーを定義できます。1つは接続制限が低いものです。
ただし、Apacheは両方のファームサーバーオブジェクトからの呼び出しに応答する必要もあります。たとえば、2つの個別のポートまたはIPアドレス（それぞれ（ファーム/ファームサーバー）の組み合わせで使用される）で呼び出されます。次に、2つのアプリケーションサーバーエントリポイントを定義できますか。つまり、2つのポートまたはIPアドレス（ファームごとに1つ）で応答するようにApacheフロントエンドアプリケーション（/ vhost？）を装備できますか？私はマニュアルにあまり時間をかけたくないので、これは多少の推測作業によるものですが、実際にAppDirector GUIとApacheを見ると、かなりエレガントにこれを解決できると思います。
接続制限の設定には少し癖があります。物理サーバーからの接続制限p.140：
"Connection Limit
Maximum number of Client Table entries that can run simultaneously on
the physical server. This depends on the farm’s Sessions mode (see
Sessions Modes, page 150). When the limit is reached, new requests are
no longer directed to this server. All open sessions are continued.
When the Connection Limit parameter is configured to 0 (default), this
mechanism is disabled for this physical server and there is no user
number limit.
Note: When configuring the physical server, ensure that the Connection
Limit in the farm servers with the same Server Name is lower than or
equal to the Connection Limit in the physical server. Total number of
active sessions that run simultaneously on the farm servers must not
be higher than the Connection Limit value defined on the physical server."
したがって、無制限の「デフォルト」のファームサーバーに対して非常に高い接続制限（ユーザーベースを通じて可能な最大数までの広いマージン）を定義し、「ログインした」ファームサーバーの接続制限を次のように設定する必要があります。あなたがする必要があるように低い。物理サーバーの定義では、目的のセッション制限をアクティブにするための前提条件として、2つの合計を接続制限として持つ必要があります。
あなたの質問にもこの要件があります：
After the specified session limit has been reached, the next user should be
directed to a custom error page.
これは、ユーザーガイドp.134では「HTTPサービスページなし」と呼ばれています。
When all servers belonging to a farm cannot be used for a specific
session, AppDirector can reply to a Web request (destined to port 80)
with a simple Web page, indicating that the service is currently not
available. Servers that cannot be used for a session include servers
in Not In Service or in No New Sessions mode. No HTTP Service Page is
configured for each farm. Each Web page is limited to 1K of HTML code.
モニタリングの部分については、徹底的な調査は行っていませんが、ここに私が考えていることがあります。
track the current number of sessions for monitoring purposes
AppDirectorにMIBがあるようです。おそらく、正しいOIDを通常どおり見つけるのは面倒ですが、お好みのツールにたどり着くことができます。
whitelist the monitoring server (which is issuing queries to the webapp
periodically) and exempt it from the limit.
これはいくつかの創造的な思考を必要とする可能性があります。 AppDirectorにこの機能のテンプレートが含まれていないと想定すると、次のようになります。
- 「ログイン」ファーム外のURIは、セッション制限の影響を受けません。監視してください、とにかくそれは同じバックエンドサーバーです。
- 代わりにAppDirectorヘルスチェックを使用してください。これらのチェックは、課したセッション制限にカウントされない可能性があります。ただし、監視サーバーにアラートを渡す方法を見つけてください:-)
- ヘルスチェックに合格する3番目のファームをセットアップします。乱雑ですが、うまくいきます。
AppDirectorで解決できない場合は、少しコーディングが必要な別の方法を以下に示します。私は次のように問題に取り組みます：
- ループで、Apacheログファイルを読み続けます（そしてlogrotateで再び開きます）
- ユーザーが（ログインだけでなく）任意のページにアクセスしたときに、それらをiptablesホワイトリストに追加します
- ユーザーがログアウトしたとき、または非アクティブになった後（アクティブなセッションのタイマーを維持してください！）、ホワイトリストから削除します。
- ホワイトリストがいっぱいの場合は、ホワイトリストにないすべてのトラフィックを特別なポートにリダイレクトします
- あなたのカスタムエラーでそのポートで簡単な仮想ホストを実行してください
セッション数のグラフ化は、iptablesチェーンの長さをグラフ化するのと同じくらい簡単になります。監視サーバーは、常に常にホワイトリストに登録できます。