Как ограничить количество сеансов?

Мне нужен способ отслеживать и ограничивать веб-сессии веб-приложением. «Сеанс» определяется как отдельный пользователь, просматривающий страницы указанного веб-приложения. Я думаю, что это может быть переведено на:

• сеанс определяется как кортеж в качестве <clientIP,vHost>альтернативы <clientIP,serverIP,serverPort>или <cookie,vHost>, в зависимости от уровня и доступных данных
• сеанс начинается после того, как пользователь отправил данные аутентификации на определенный URI входа
• сеанс заканчивается после того, как пользователь нажал на определенный URI выхода из системы
• сеанс заканчивается, если указанный тайм-аут истек после того, как клиент запросил последний объект

После того, как указанный предел сеанса будет достигнут, следующий пользователь должен быть направлен на пользовательскую страницу ошибки. Мне также нужен способ отслеживания текущего количества сеансов для целей мониторинга и возможность внесения в белый список сервера мониторинга (который периодически отправляет запросы в веб-приложение) и освобождения его от ограничения.

С чем я могу работать:

• RadWare AppDirector, где веб-приложение имеет собственную ферму и работает в режиме обратного прокси
• Apache 2.2
• SLES 11 SP2

Я бы предпочел не привлекать дополнительный прокси-сервер, хотя рассмотрел бы его, если бы не осталось других вариантов.

Обоснование всего этого заключается в том, что вышеупомянутое веб-приложение легко перегружается и начинает беспорядочно отклонять запросы, раздражая работающих пользователей, которые (как правило) теряют данные ввода формы в процессе. Устанавливая предел, при котором условие перегрузки является менее вероятным, мы надеемся создать четко определенное условие отказа, при котором пользователям будет предложено вернуться позже, если нагрузка может резко возрасти.

Редактировать : веб-приложение представляет собой трехуровневую реализацию, причем первый уровень (уровень представления, реализованный в виде кода CGI в Apache vHost) довольно прост и явно ограничен базовой обработкой ошибок и балансировкой нагрузки запросов между серверами приложений. Он не создает какой-либо значительной нагрузки на веб-серверы, на которых он работает - поэтому мы запускаем его в простом режиме отработки отказа (без балансировки нагрузки) в ферме AppDirector, что должно несколько упростить ситуацию.

Все, что находится за пределами этого пункта, является для нас в основном черным ящиком - на уровне данных у нас есть база данных MSSQL, но практически невозможно получить какую-либо значимую информацию о структуре таблицы от поставщика. Серверы приложений с закрытым исходным кодом, поставщик использовал довольно комплексную структуру для реализации, но, похоже, не может ответить даже на менее сложные вопросы, связанные с работой.

Проблема, которую вы в конечном итоге пытаетесь решить, связана с возможностями приложения - и именно здесь вы должны решить проблему. Ни один из упомянутых вами компонентов не имеет ничего общего с управлением сеансами для приложения HTTP.

Есть некоторые приемы, которые вы можете применить с последним модулем в iptables или использовать fail2ban в противоположность цели, для которой он был разработан - но оба они требуют очень детального понимания инструментов и предметной области. Вы можете реализовать управление доступом на уровне этих компонентов, но на основе опубликованной информации о состоянии из приложения о количестве сеансов.

Мне также нужен способ отслеживать текущее количество сеансов для целей мониторинга

Предполагая, что на данный момент приложение является черным ящиком без возможности модификации / инструментария (что крайне маловероятно), вы можете получить эту информацию из ваших журналов apache, включив cookie-фильтр сеанса или отфильтровывая журналы, чтобы поддерживать список активных файлов cookie - и удаляйте записи из списка, если они совпадают с URL-адресом выхода из системы или не были просмотрены для TTL.

Это не совсем то, что вы просите, но я уже сделал следующее с балансировщиком нагрузки F5:

• Подсчитайте количество почтовых запросов на странице входа.
• Задержка пользователей, если число входов в секунду превышает первый лимит
• Отправлять пользователей на страницу обслуживания, если число входов в секунду превышает второй предел

Поскольку сайт иногда находился под большой нагрузкой (скачки), это помогло.

Эта проблема решаема как с помощью RadWare AppDirector, так и (для полноты), вероятно, также с помощью Apache mod_security согласно вашему превосходному выводу в комментарии ниже.

Я считаю, что для решения AppDirector можно создать две фермы, сопоставленные с одним и тем же внутренним сервером. Эти фермы могут иметь различные критерии и условия эксплуатации, применяемые к ним. Одна ферма будет «по умолчанию», а другая будет отвечать на URI, которые вы определяете как «сеанс». Последний получит ограничение на количество сеансов, которые он принимает в балансировщике нагрузки.

Теперь я собираюсь заменить ваш термин "сеанс" на "вход в систему" по двум причинам:

• Это позволяет избежать двусмысленности, поскольку оно четко определяет желаемое состояние, в котором пользователь проходит аутентификацию.
• В Руководстве пользователя и графическом интерфейсе AppDirector термин «соединение» переопределяется, чтобы иметь значение для всех практических целей, идентичных «сеансу», см. Ниже. Это добавляет путаницу, которую мы пытаемся избежать.

Также можно показать страницу с сожалением, если ферма «вошла в систему» ​​достигла выбранного лимита подключения.

Прежде чем перейти к тому, как, я должен четко заявить, что у меня нет опыта работы с продуктом AppDirector, но я ежедневно администрирую конкурирующий и немного менее продвинутый балансировщик нагрузки. Продукт, который я использую, может реализовать этот сценарий сразу. Я нашел информацию в Руководстве пользователя AppDirector и о том, какая онлайн-документация доступна, что предполагает, что то же самое относится и к AppDirector. Однако, хотя понятия похожи, терминология другая. Я просто делаю акт «когда в Риме» в отношении формулировок, в надежде сделать это совершенно правильно, не будучи слишком очевидным идиотом.

Самым большим препятствием было получение доступа к руководству, которое недоступно, если только вы не являетесь активным клиентом. Посредством некоторого поиска в Google удалось найти старую версию, которая, я надеюсь, не слишком устарела, я также нашел пару статей в базе знаний и эту ссылку: Radware AppDirector - Configuration: Basic Application .

Вот черновик решения, интерпретируемый в основном через Руководство пользователя:

Вход клиента в балансировщик нагрузки осуществляется через VIP, который используется для подключения сеансов «по умолчанию» и «сеансов, вошедших в систему». Это достигается с помощью политики 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 описан таким образом в Руководстве пользователя стр.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, описаны на стр.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."

Как видно из ссылки на Основное приложение , можно, например, создать политику L7, оценивающую шаблоны URI для маршрутизации в разные фермы. Сформированные шаблоны URI '^ / login? = True' и '^ / loggedin' могут быть перенаправлены на вашу ферму «вошли в систему». Составленный шаблон '^ / logout' (и все другие URI) также может быть перенаправлен на ферму «по умолчанию».

Ферма определяется в Руководстве пользователя, с.121, таким образом: «Ферма AppDirector - это группа сетевых серверов, которые предоставляют одну и ту же услугу [...] Сервер, который предоставляет несколько услуг, может использоваться в нескольких фермах».

Сервер дополнительно дифференцируется путем разделения определения внутреннего сервера на два уровня: объектный уровень «Физический сервер», который представляет IP-адрес сервера, и объектный уровень «Сервер фермы», который представляет службы, работающие на одном или нескольких физических серверах. ,

В соответствии с «Руководством пользователя AppDirector» ограничение сеанса в ферме может быть выполнено для каждого объекта «Сервер фермы», определенного для фермы (а также с помощью других средств), в дополнение к объекту «Физический сервер». Это описано среди других мест на стр.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."

Таблица клиента и ее «обычный режим» определены на стр. 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"

На снимке экрана с окном определения сервера на странице « Основное приложение» поле ограничения подключения к серверу отображается прямо рядом с полем ограничения полосы пропускания.

Таким образом, немного в зависимости от конфигурации, но для целей этого ответа «соединение», как определено через таблицу клиента, и «сеанс», как вы определено, по сути, в конечном итоге является одним и тем же. И ограничение на этот эффект может быть наложено на один объект сервера в ферме.

Поскольку AppDirector различает физические серверы и серверы фермы, можно определить два сервера фермы, сопоставляемых с вашим объектом физического сервера Apache, один из которых имеет низкий предел подключения.

Однако Apache также должен отвечать на вызовы от обоих объектов сервера фермы, например, через вызовы на двух отдельных портах или IP-адресах - один используется каждой комбинацией (сервер фермы / фермы). Тогда возникает вопрос, можете ли вы определить две точки входа на сервер приложений? т.е. можете ли вы оборудовать ваше внешнее приложение Apache (/ vhost?) для ответа по двум портам или IP-адресам (по одному на ферму)? Это всего лишь небольшая работа с догадками, так как я не хочу тратить слишком много времени на руководство, но я уверен, что вы могли бы решить это довольно элегантно, глядя на графический интерфейс AppDirector и Apache.

Установка ограничения соединения имеет небольшую причуду. С физических серверов, предел подключения стр.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."

Поэтому вам нужно будет определить очень высокий лимит подключений (с широким полем для максимально возможного числа через вашу пользовательскую базу) для неограниченного сервера фермы «по умолчанию» и установить предел подключений для сервера фермы, «вошедшего в систему» ​​как так низко, как ты должен. Определение физического сервера должно иметь сумму двух в качестве своего предела соединения в качестве предварительного условия для активации желаемого предела сеанса.

У вас также есть это требование в вашем вопросе:

After the specified session limit has been reached, the next user should be
directed to a custom error page.

Это называется «Нет страницы службы HTTP» в Руководстве пользователя, с.134:

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, они, скорее всего, не будут учитываться в отношении установленного вами предела сеанса. Найдите способ передавать оповещения на сервер мониторинга :-)
• Создайте третью ферму, через которую вы будете проходить проверки здоровья. Грязно, но это сработает.

Если AppDirector не может вам помочь, вот другой подход, который потребует немного кодирования. Я бы решил эту проблему следующим образом:

• В цикле продолжайте читать файл журнала apache (и снова откройте его при logrotate)
• Когда пользователь заходит на любую страницу (не только для входа), добавьте их в белый список iptables
• Когда пользователь выходит из системы или после неактивности (поэтому оставьте таймеры для активных сеансов!), Удалите их из белого списка
• Если белый список заполнен, перенаправьте весь трафик, не входящий в белый список, на специальный порт
• Запустите простой vhost на этом порту с вашей пользовательской ошибкой

График количества сеансов становится таким же простым, как и график длины цепочки iptables. Сервер мониторинга просто может быть всегда в белом списке.