Làm thế nào để hạn chế số phiên?


8

Tôi cần một cách để theo dõi và giới hạn các phiên web cho một ứng dụng web. "Phiên" được định nghĩa một cách lỏng lẻo là một người dùng đang duyệt các trang của ứng dụng web đã nói. Tôi nghĩ rằng nó có thể được dịch sang:

  • một phiên được định nghĩa là một tuple <clientIP,vHost>thay thế là <clientIP,serverIP,serverPort>hoặc <cookie,vHost>, tùy thuộc vào lớp và dữ liệu có sẵn
  • một phiên bắt đầu sau khi người dùng đã gửi dữ liệu xác thực đến URI đăng nhập được xác định
  • một phiên kết thúc sau khi người dùng đã nhấn URI đăng xuất được xác định
  • một phiên kết thúc nếu hết thời gian chỉ định đã hết sau khi khách hàng yêu cầu đối tượng cuối cùng

Sau khi đạt đến giới hạn phiên được chỉ định, người dùng tiếp theo sẽ được chuyển đến trang lỗi tùy chỉnh. Tôi cũng cần một cách để theo dõi số phiên hiện tại cho mục đích giám sát và khả năng lập danh sách trắng máy chủ giám sát (đang phát hành truy vấn cho ứng dụng web theo định kỳ) và miễn trừ giới hạn.

Những gì tôi có thể làm việc với:

  • RadWare AppDirector nơi ứng dụng web có một trang trại riêng được xác định và đang chạy ở chế độ proxy ngược
  • Apache 2.2
  • SLES 11 SP2

Tôi không muốn liên quan đến một máy chủ proxy bổ sung, mặc dù sẽ xem xét nó nếu không còn lựa chọn nào khác.

Lý do đằng sau tất cả những điều này là ứng dụng web nói trên dễ bị quá tải và bắt đầu từ chối các yêu cầu một cách thất thường, khiến người dùng làm việc (thường) mất dữ liệu nhập biểu mẫu trong quá trình. Bằng cách chỉ định một giới hạn trong đó điều kiện quá tải ít có khả năng, chúng tôi hy vọng sẽ tạo ra một điều kiện lỗi được xác định rõ trong đó người dùng sẽ được yêu cầu quay lại sau nếu tải có khả năng tăng đột biến.

Chỉnh sửa : ứng dụng web là một triển khai 3 tầng với tầng thứ nhất (lớp trình bày, được triển khai dưới dạng mã CGI trong Apache vhost) khá đơn giản và dường như bị giới hạn trong việc xử lý lỗi cơ bản và cân bằng tải yêu cầu giữa các máy chủ ứng dụng. Nó không áp đặt bất kỳ tải đáng kể nào cho các máy chủ web mà nó chạy - đây là lý do tại sao chúng tôi đang chạy nó ở chế độ chuyển đổi dự phòng (không cân bằng tải) trong trang trại AppDirector, được cho là để đơn giản hóa mọi thứ.

Tất cả mọi thứ nằm ngoài điểm này về cơ bản là một hộp đen đối với chúng tôi - ở tầng dữ liệu chúng tôi có cơ sở dữ liệu MSSQL, nhưng gần như không thể nhận được bất kỳ thông tin có ý nghĩa nào về cấu trúc bảng từ nhà cung cấp. Các máy chủ ứng dụng là nguồn đóng, nhà cung cấp đã sử dụng một khung khá toàn diện để thực hiện, nhưng dường như không thể trả lời các câu hỏi liên quan đến hoạt động ít phức tạp hơn.


Bạn có thể cung cấp chi tiết chung về ứng dụng web? Có giống nhau trên mỗi vhost không? Hoặc bạn không cung cấp thông tin chi tiết, vì bạn có thể muốn một giải pháp độc lập với ứng dụng web? Đây có phải là một ứng dụng web độc quyền?
lsmooth

Sau khi kết nối bị đóng, do không hoạt động, ai đó có thể tiếp tục phiên sử dụng cookie phiên (nếu không đạt được thời gian chờ của ứng dụng)?
manjiki

@jijix đây là một trường hợp biên giới được coi là hiếm khi không bận tâm về nó nếu nó làm tăng thêm sự phức tạp của việc thực hiện. Ngoài ra, tôi nghĩ tốt nhất có thể được chỉ định là "khởi tạo lại phiên mà không kiểm tra giới hạn phiên" .
the-wợi

Tôi thường làm điều này bằng cách đếm các url "điển hình" trong nhật ký truy cập httpd. Con số thô đồng thời chúng ta đang nói đến ở đây là gì? Có lẽ giới hạn luồng có thể giúp ở đây về phía httpd?
Nils

Tôi biết HAProxy có thể giới hạn số lượng kết nối. Nhưng bạn đang hỏi điều gì đó hơi khác một chút ...
Matt

Câu trả lời:


5

Vấn đề cuối cùng bạn đang cố gắng giải quyết là với khả năng của ứng dụng - và đó là nơi bạn nên giải quyết vấn đề. Không có thành phần nào bạn đề cập có liên quan đến quản lý phiên cho ứng dụng HTTP.

Có một số thủ thuật bạn có thể áp dụng với mô-đun gần đây trong iptables hoặc sử dụng fail2ban theo cách ngược lại với mục đích mà nó được thiết kế cho - nhưng cả hai đều đòi hỏi sự hiểu biết rất rõ ràng về các công cụ và miền vấn đề. Bạn có thể thực hiện kiểm soát truy cập ở cấp độ của các thành phần này nhưng được điều khiển bởi thông tin trạng thái được công bố từ ứng dụng về số phiên.

Tôi cũng cần một cách để theo dõi số phiên hiện tại cho mục đích giám sát

Giả sử, hiện tại, ứng dụng là một hộp đen không có phạm vi sửa đổi / thiết bị (rất khó khả thi), bạn có thể lấy thông tin này từ nhật ký apache của mình bằng cách bao gồm cookie phiên - lọc hoặc cắt đuôi nhật ký để duy trì danh sách các cookie hoạt động - và xóa các mục khỏi danh sách khi chúng trùng với URL đăng xuất hoặc chưa được nhìn thấy cho TTL.


Quên những câu hỏi của tôi ở trên, đây chính xác là những gì tôi đang nhận được.
lsmooth

Bạn có chắc chắn rằng RadWare AppDirector không thể giải quyết vấn đề này ít nhất là trong điều trị mở rộng? - kiểm soát phiên được yêu cầu để ngăn chặn quá tải nút có thể đạt được bằng các phương tiện khác.
Veniamin

Không, tôi không chắc chắn - như tôi đã nói ở trên, bạn có thể làm mờ việc quản lý phiên ở nơi khác trong ngăn xếp - nhưng thật khó khăn , RẤT NHIỀU việc thực hiện sai vị trí. Khắc phục sự cố xảy ra sự cố dễ dàng hơn nhiều.
symcbean

Nếu bạn xem xét vị trí thích hợp để quản lý phiên là một mô-đun được tích hợp trong ứng dụng hoặc ở nơi khác trên cơ sở mỗi nút thì không rõ làm thế nào để làm cho nó hoạt động cùng với cân bằng tải ở cấp AppDirector.
Veniamin

Ý tưởng sử dụng nhật ký apache để theo dõi phiên có một số giá trị. Đối với phần còn lại - bạn biết tôi chưa viết ứng dụng và có rất ít (nếu có) ảnh hưởng đến sự phát triển hơn nữa. Đó không phải là quyết định của tôi khi đưa nó vào vị trí, thẩm quyền của tôi chỉ giới hạn ở cơ sở hạ tầng mà nó chạy. Điểm mà ứng dụng không tối ưu đã được quản lý làm rõ, nhưng ngay cả khi điều này có thể thay đổi bất cứ điều gì, mọi thay đổi sẽ mất một lượng thời gian đáng kể Vì vậy, công việc hiện tại của tôi là tìm ra một chế độ hoạt động "tốt như nó được".
the-wợi

1

Đây không phải là chính xác những gì bạn đang yêu cầu, nhưng tôi đã thực hiện như sau với bộ cân bằng tải F5:

  • Đếm số lượng yêu cầu bài viết trên trang đăng nhập.
  • Trì hoãn người dùng nếu đăng nhập mỗi giây vượt quá giới hạn đầu tiên
  • Gửi người dùng đến trang bảo trì nếu thông tin đăng nhập mỗi giây vượt quá giới hạn thứ hai

Vì trang web đôi khi chịu tải nặng (các cuộc đua ngựa), nó đã giúp ích.


Cảm ơn ý tưởng, tôi cần kiểm tra với các anh chàng AppDirector của chúng tôi nếu chúng tôi có thể thực hiện một cái gì đó tương tự.
the-wợi

@ syirecton-dj: nếu bạn cần kiểm tra xem bạn có thể thực hiện một cái gì đó như thế này không (thực sự không giải quyết được vấn đề, BTW) và bạn không thể sửa ứng dụng, thì thực sự bạn đang gặp rắc rối. Về phản xạ tôi có thể nghĩ ra ít nhất 2 cách nữa để giải quyết vấn đề - nhưng cả hai đều đòi hỏi kỹ thuật - và thực hiện không đúng sẽ làm cho vấn đề tồi tệ hơn là tốt hơn. Bạn cần giúp đỡ nhiều hơn bạn sẽ nhận được ở đây.
symcbean

@symcbean Không có gì tôi có thể làm sẽ giải quyết vấn đề, đó là thiếu trình độ trong nhà phát triển và nhân viên hỗ trợ của nhà cung cấp và quyết định sử dụng ứng dụng này trong sự thiếu hiểu biết. Nếu bạn có ý tưởng khác, tôi sẽ rất vui khi nghe về chúng. "Yêu cầu" không phải là vấn đề miễn là nó không làm tăng thêm sự phức tạp trong các hoạt động hàng ngày.
the-wợi

1

Vấn đề này có thể giải quyết được bằng cách sử dụng RadWare AppDirector và (có thể hoàn thành) cũng có thể bằng cách sử dụng mod_security của Apache theo phát hiện xuất sắc của bạn trong bình luận bên dưới.

Đối với giải pháp AppDirector tôi tin rằng có thể tạo hai trang trại ánh xạ tới cùng một máy chủ phụ trợ. Những trang trại này có thể có các tiêu chí và điều kiện hoạt động khác nhau được áp dụng cho chúng. Một trang trại sẽ là "mặc định" và trang trại kia sẽ trả lời cho URI: s mà bạn xác định là "phiên". Cái sau sẽ có giới hạn về số lượng phiên mà nó chấp nhận trong bộ cân bằng tải.

Tôi từ bây giờ sẽ thay thế cụm từ "phiên" của bạn cho "đăng nhập" vì hai lý do:

  • Nó tránh sự mơ hồ vì nó xác định rõ ràng trạng thái mong muốn trong đó người dùng được xác thực.
  • Hướng dẫn sử dụng và GUI của AppDirector xác định lại thuật ngữ "kết nối" để có ý nghĩa cho tất cả các mục đích thực tế giống với "phiên", xem bên dưới. Điều này thêm sự nhầm lẫn mà chúng tôi cố gắng tránh.

Cũng có thể hiển thị trang xin lỗi nếu trang trại "đăng nhập" đã đạt đến giới hạn kết nối đã chọn.

Trước khi tìm hiểu, tôi phải nói rõ rằng tôi không có kinh nghiệm vận hành sản phẩm AppDirector, nhưng vẫn quản lý một bộ cân bằng tải cạnh tranh và hơi kém tiên tiến trên cơ sở hàng ngày. Sản phẩm tôi sử dụng có thể thực hiện kịch bản này ngay lập tức. Tôi đã tìm thấy thông tin thông qua Hướng dẫn sử dụng AppDirector và tài liệu trực tuyến nào có sẵn cho thấy điều tương tự cũng đúng với AppDirector. Tuy nhiên, trong khi các khái niệm là tương tự nhau, thuật ngữ là khác nhau. Tôi chỉ đơn giản là thực hiện một hành động khi ở trong rome liên quan đến từ ngữ, hy vọng làm cho nó hoàn toàn đúng mà không quá rõ ràng là một kẻ ngu ngốc.

Rào cản lớn nhất là truy cập vào một hướng dẫn, điều này không có sẵn trừ khi một khách hàng đang hoạt động. Thông qua một số thông tin có thể tìm thấy một phiên bản cũ mà tôi hy vọng không quá lỗi thời, tôi cũng tìm thấy một vài bài viết về kiến ​​thức và liên kết này: Radware AppDirector - Cấu hình: Ứng dụng cơ bản .

Đây là một dự thảo giải pháp, như được giải thích chủ yếu thông qua Hướng dẫn sử dụng:

Mục nhập của khách hàng vào bộ cân bằng tải được thực hiện thông qua VIP được sử dụng để kết nối cả phiên "mặc định" và "phiên đăng nhập". Điều này đạt được thông qua chính sách L4 theo p.99 trong Hướng dẫn sử dụng:

"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.

Chính sách L4 có thể được gắn với các chính sách L7 được sử dụng để chọn trang trại phù hợp. Quy trình chính sách L7 được mô tả như vậy trong Hướng dẫn sử dụng tr.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."

Các phương thức có sẵn để xác định hành vi L7 được giải mã trên p.106, trong đó bạn có thể chọn một phương thức phù hợp để chọn định tuyến đến Trang trại "đã đăng nhập" thay vì đến trang trại "mặc định":

"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."

Như đã thấy trong liên kết Ứng dụng cơ bản , chẳng hạn, người ta có thể tạo chính sách L7 đánh giá các mẫu URI để định tuyến đến các trang trại khác nhau. Các mẫu URI được tạo thành '^ / login? = True' và '^ / login' có thể được định tuyến đến trang trại "đã đăng nhập" của bạn. Mẫu đã tạo '^ / logout' (và tất cả các URI: s khác) có thể được định tuyến tương tự đến trang trại "mặc định".

Farm được định nghĩa bởi Hướng dẫn sử dụng tr.121, do đó: "Trang trại AppDirector là một nhóm các máy chủ được nối mạng cung cấp cùng một dịch vụ [...] Một máy chủ cung cấp nhiều dịch vụ có thể được sử dụng trong nhiều trang trại."

Một máy chủ được phân biệt rõ hơn thông qua việc tách định nghĩa của máy chủ phụ trợ thành hai lớp, lớp đối tượng 'Máy chủ vật lý' đại diện cho địa chỉ IP của máy chủ và lớp đối tượng 'Máy chủ nông trại' đại diện cho các dịch vụ chạy trên một hoặc nhiều Máy chủ vật lý .

Giới hạn phiên trên trang trại có thể được thực hiện theo 'Hướng dẫn sử dụng AppDirector' cho mỗi đối tượng Máy chủ Farm được xác định cho trang trại (cũng như thông qua các phương tiện khác) ngoài đối tượng Máy chủ vật lý. Điều này được mô tả trong số những nơi khác trên tr.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."

Bảng khách hàng và 'Chế độ thông thường' được xác định trên tr.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"

Trong ảnh chụp màn hình của cửa sổ định nghĩa máy chủ trên trang Ứng dụng cơ bản , hộp giới hạn kết nối máy chủ được nhìn thấy ngay bên cạnh hộp giới hạn băng thông.

Vì vậy, một chút tùy thuộc vào cấu hình nhưng cho mục đích của câu trả lời này, một "kết nối" như được xác định thông qua Bảng khách hàng và "phiên" như được xác định bởi bạn về cơ bản cuối cùng là cùng một thứ. Và giới hạn cho hiệu ứng đó có thể được áp dụng cho mỗi đối tượng máy chủ trong trang trại.

Vì AppDirector phân biệt giữa máy chủ vật lý và máy chủ nông trại, có thể xác định hai máy chủ trang trại ánh xạ tới đối tượng máy chủ vật lý Apache của bạn, một máy chủ có giới hạn kết nối thấp.

Tuy nhiên, Apache cũng cần trả lời các cuộc gọi từ cả hai đối tượng máy chủ nông trại, ví dụ như thông qua việc được gọi trên hai cổng hoặc địa chỉ IP riêng biệt - một cổng được sử dụng bởi mỗi kết hợp (máy chủ nông trại / trang trại). Sau đó, câu hỏi trở thành, bạn có thể xác định hai điểm nhập máy chủ ứng dụng không? tức là bạn có thể trang bị ứng dụng giao diện người dùng Apache (/ vhost không?) của mình để trả lời trên hai cổng hoặc địa chỉ IP (một cho mỗi trang trại) không? Điều này thông qua một chút công việc đoán vì tôi không muốn dành quá nhiều thời gian cho hướng dẫn sử dụng, nhưng tôi chắc chắn rằng bạn có thể giải quyết vấn đề này khá thanh lịch khi thực sự nhìn vào GUI AppDirector và Apache.

Đặt giới hạn kết nối có một chút giải quyết. Từ máy chủ vật lý, giới hạn kết nối tr.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."

Do đó, bạn cần xác định Giới hạn kết nối rất cao (với biên độ rộng đến số lượng tối đa có thể thông qua cơ sở người dùng của bạn) cho máy chủ nông trại "mặc định" không bị hạn chế và đặt Giới hạn kết nối cho máy chủ nông trại "đã đăng nhập" là thấp như bạn phải Định nghĩa máy chủ vật lý sẽ cần phải có tổng của hai là Giới hạn kết nối của nó, như một điều kiện tiên quyết để kích hoạt giới hạn phiên mong muốn.


Bạn cũng có yêu cầu này trong câu hỏi của bạn:

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

Điều này được gọi là 'Không có trang dịch vụ HTTP' trong Hướng dẫn sử dụng, tr.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.

Đối với phần giám sát tôi chưa thực hiện nghiên cứu kỹ lưỡng nhưng đây là những gì tôi nghĩ:

track the current number of sessions for monitoring purposes

AppDirector dường như có MIB. Có lẽ là một nỗi đau để tìm đúng OID như thường lệ, nhưng bạn có thể có thể đưa nó vào công cụ bạn chọn.

whitelist the monitoring server (which is issuing queries to the webapp
periodically) and exempt it from the limit.

Điều này có thể đòi hỏi một số suy nghĩ sáng tạo. Giả sử AppDirector không bao gồm một mẫu cho quyền này ngay lập tức, làm thế nào về:

  • Các URI bên ngoài trang trại "đã đăng nhập" sẽ không bị ảnh hưởng bởi giới hạn phiên. Vì vậy, theo dõi đi, dù sao nó cũng là máy chủ phụ trợ.
  • Thay vào đó, hãy sử dụng kiểm tra sức khỏe AppDirector, chúng có thể sẽ không được tính vào giới hạn phiên bạn áp đặt. Tìm cách chuyển thông báo đến máy chủ theo dõi của bạn mặc dù :-)
  • Thiết lập một trang trại thứ ba, thông qua đó bạn vượt qua kiểm tra sức khỏe. Lộn xộn, nhưng nó sẽ làm việc.

1
Cho đến nay, tôi đã thấy rằng mô-đun mod_security2 có thể xử lý phiên theo cách trông rất giống với những gì tôi đã chỉ định - safe.jwall.org/blog/2009/01/08/1231374852674.html . Tôi sẽ thực hiện một số nghiên cứu thêm về ý tưởng của bạn về 2 trang trại, nếu việc triển khai như vậy là có thể, nó chắc chắn sẽ đơn giản hóa mọi thứ.
the-wợi

Phản hồi từ bộ phận hỗ trợ kỹ thuật của Radware: "Trong AD, chúng tôi chỉ có thể giới hạn băng thông cho mỗi trang trại. [...] Phương pháp [A] để giới hạn tổng số phiên trên cơ sở trang trại hiện không khả dụng." Vậy là mod_security rồi.
the-wợi

Ok, thật bất ngờ. Trừ khi tôi bỏ lỡ điều gì đó, tôi vẫn nghĩ rằng việc đóng cửa trang trại thông qua kiểm tra sức khỏe thất bại sẽ là một giải pháp sạch hơn. Phát hiện của bạn về mod_security rất thú vị bất kể.
ErikE

Có thể mặc dù sự hỗ trợ hơi hẹp trong việc diễn giải câu hỏi, nhưng nó xuất hiện giới hạn phiên ở cấp độ máy chủ trong AppDirector là có thể (chắc chắn có một số logic). Tôi đã googled một số liên kết, đây là một: kb.radware.com/questions/2829/ Khăn
ErikE

Bài viết Radware KB liên quan đến LinkProof - một trình tăng tốc mạng WAN. Tôi không biết phần mềm nào đang chạy và nếu các phương tiện tương tự sẽ tồn tại cho AppDirector. BTW: Mã xử lý phiên chắc chắn một phần của bộ tính năng của AppDirector - nó có một bảng phiên trông giống hệt như những gì tôi mong đợi. Nhưng rõ ràng, không có cách nào để áp đặt một giới hạn về số lượng sesssions - chỉ trên các kết nối. Điều tôi có thể nhận được nhiều nhất từ ​​nó là giới hạn số lần truy cập trên một trang nhất định (ví dụ: trang đăng nhập) trên mỗi đơn vị thời gian như "khác" mà Eric đề xuất.
the-wợi

0

Nếu AppDirector không thể giúp bạn, thì đây là một cách tiếp cận khác sẽ cần một chút mã hóa. Tôi sẽ giải quyết vấn đề như sau:

  • Trong một vòng lặp, tiếp tục đọc tệp nhật ký apache (và mở lại nó trên logrotate)
  • Khi người dùng truy cập bất kỳ trang nào (không chỉ đăng nhập), hãy thêm họ vào danh sách trắng iptables
  • Khi người dùng đăng xuất hoặc sau khi không hoạt động (vì vậy hãy giữ bộ hẹn giờ cho các phiên hoạt động!), Hãy xóa chúng khỏi danh sách trắng
  • Nếu danh sách trắng đã đầy, hãy chuyển hướng tất cả lưu lượng truy cập không thuộc danh sách trắng sang một cổng đặc biệt
  • Chạy một vhost đơn giản trên cổng đó với lỗi tùy chỉnh của bạn

Vẽ đồ thị số phiên trở nên đơn giản như vẽ đồ thị độ dài của chuỗi iptables. Máy chủ giám sát có thể luôn luôn nằm trong danh sách trắng.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.