Bagaimana cara membatasi jumlah sesi?


8

Saya perlu cara untuk melacak dan membatasi sesi web ke aplikasi web. "Sesi" secara longgar didefinisikan sebagai satu-satunya pengguna yang menelusuri halaman aplikasi web tersebut. Saya pikir itu dapat diterjemahkan ke:

  • sebuah sesi didefinisikan sebagai tuple <clientIP,vHost>sebagai alternatif <clientIP,serverIP,serverPort>atau <cookie,vHost>, tergantung pada layer dan data yang tersedia
  • sesi dimulai setelah pengguna mengirim data otentikasi ke URI login yang ditentukan
  • sesi berakhir setelah pengguna menekan URI logout yang ditentukan
  • sesi berakhir jika batas waktu yang ditentukan telah kedaluwarsa setelah klien meminta objek terakhir

Setelah batas sesi yang ditentukan telah tercapai, pengguna berikutnya harus diarahkan ke halaman kesalahan khusus. Saya juga membutuhkan cara untuk melacak jumlah sesi saat ini untuk keperluan pemantauan dan kemampuan untuk memasukkan daftar putih server pemantauan (yang mengeluarkan permintaan ke webapp secara berkala) dan membebaskannya dari batas.

Apa yang bisa saya kerjakan:

  • RadWare AppDirector di mana aplikasi web memiliki layanan sendiri yang ditentukan dan berjalan dalam mode proxy terbalik
  • Apache 2.2
  • SLES 11 SP2

Saya lebih suka tidak melibatkan server proxy tambahan, meskipun akan mempertimbangkannya jika tidak ada pilihan lain yang tersisa.

Alasan di balik semua ini adalah bahwa aplikasi web tersebut dengan mudah kelebihan beban dan mulai menolak permintaan secara tidak menentu, mengecewakan pengguna yang bekerja yang (biasanya) kehilangan data entri formulir dalam proses. Dengan menetapkan batas di mana kondisi kelebihan muatan lebih kecil kemungkinannya, kami berharap dapat menciptakan kondisi kegagalan yang terdefinisi dengan baik di mana pengguna akan diminta untuk kembali nanti jika beban cenderung meningkat.

Sunting : aplikasi web adalah implementasi 3-tier dengan tier pertama (lapisan presentasi, diimplementasikan sebagai kode CGI dalam Apache vHost) yang agak sederhana dan tampaknya terbatas pada penanganan kesalahan dasar dan meminta penyeimbangan muatan di antara server aplikasi. Itu tidak memaksakan beban signifikan pada server web yang dijalankan - ini sebabnya kami menjalankannya dalam mode failover belaka (tanpa penyeimbangan beban) di pertanian AppDirector, yang seharusnya menyederhanakan banyak hal.

Segala sesuatu di luar titik ini pada dasarnya adalah kotak hitam bagi kami - pada tingkat data kami memiliki database MSSQL, tetapi hampir tidak mungkin untuk mendapatkan informasi yang berarti tentang struktur tabel dari vendor. Server aplikasi adalah sumber tertutup, vendor telah menggunakan kerangka kerja yang agak komprehensif untuk implementasi, tetapi tampaknya tidak dapat menjawab pertanyaan terkait operasi yang bahkan lebih kompleks.


Bisakah Anda memberikan detail umum di aplikasi web? Apakah sama pada setiap vHost? Atau tidakkah Anda memberikan detailnya, karena Anda mungkin menginginkan solusi yang independen dari aplikasi web? Apakah ini aplikasi web eksklusif?
lsmooth

Setelah koneksi ditutup, karena tidak aktif, dapatkah seseorang melanjutkan sesi menggunakan cookie sesi (jika batas waktu aplikasi belum tercapai)?
manjiki

@ jijix ini adalah kasus perbatasan yang dianggap cukup langka untuk tidak dipusingkan jika menambah kompleksitas implementasi. Selain itu, saya pikir itu bisa ditentukan sebagai "instate ulang sesi tanpa memeriksa batas sesi" .
the-wabbit

Saya biasanya melakukan ini dengan menghitung url "khas" di httpd-access-log. Berapa angka konkuren kasar yang kita bicarakan di sini? Mungkin batas thread dapat membantu di sini di sisi httpd?
Nils

Saya tahu HAProxy dapat membatasi jumlah koneksi. Tetapi Anda meminta sesuatu yang sedikit berbeda ...
Matt

Jawaban:


5

Masalah yang akhirnya Anda coba selesaikan adalah dengan kapasitas aplikasi - dan di situlah Anda harus menyelesaikan masalahnya. Tidak satu pun dari komponen yang Anda sebutkan berhubungan dengan manajemen sesi untuk aplikasi HTTP.

Ada beberapa trik yang dapat Anda terapkan dengan modul terbaru di iptables atau menggunakan fail2ban dengan cara yang berlawanan dengan tujuan dirancangnya - tetapi keduanya membutuhkan pemahaman yang sangat terperinci tentang alat dan domain masalah. Anda bisa menerapkan kontrol akses di tingkat komponen ini tetapi didorong oleh informasi negara yang dipublikasikan dari aplikasi pada jumlah sesi.

Saya juga perlu cara untuk melacak jumlah sesi saat ini untuk keperluan pemantauan

Dengan asumsi, untuk saat ini, bahwa aplikasi tersebut adalah kotak hitam tanpa ruang lingkup untuk modifikasi / instrumentasi (yang sangat tidak mungkin) Anda dapat memperoleh informasi ini dari log apache Anda dengan memasukkan cookie sesi - filter atau ekor log untuk mempertahankan daftar cookie aktif - dan hapus entri dari daftar ketika mereka bertepatan dengan URL logout atau belum terlihat untuk TTL.


Lupakan pertanyaan saya di atas, inilah tepatnya yang saya maksudkan.
lsmooth

Apakah Anda yakin RadWare AppDirector tidak dapat menyelesaikan masalah ini, setidaknya dalam perawatan lanjutan? - kontrol sesi diminta untuk mencegah overloading simpul yang dapat dicapai dengan cara lain.
Veniamin

Tidak, saya tidak yakin - seperti yang saya katakan di atas, Anda dapat memalsukan manajemen sesi di tempat lain di tumpukan - tetapi banyak, JAUH lebih sulit untuk melakukannya di tempat yang salah. Memperbaiki masalah di mana masalah itu terjadi jauh lebih mudah.
symcbean

Jika Anda menganggap tempat yang tepat untuk manajemen sesi adalah modul yang terintegrasi dalam aplikasi atau di tempat lain berdasarkan per-simpul yang tidak jelas bagaimana membuatnya bekerja bersama dengan load balancing di tingkat AppDirector.
Veniamin

Gagasan menggunakan log apache untuk pelacakan sesi memiliki beberapa manfaat. Adapun sisanya - Anda tahu saya belum menulis aplikasi dan memiliki sedikit pengaruh (jika ada) pada pengembangan lebih lanjut. Itu bukan keputusan saya untuk meletakkannya, otoritas saya terbatas pada infrastruktur yang dijalankannya. Poin bahwa aplikasi ini tidak optimal telah dibuat jelas kepada manajemen, tetapi bahkan jika ini mampu mengubah apa pun, perubahan apa pun akan ambil banyak waktu. Jadi pekerjaan saya saat ini adalah menemukan mode operasi "sebagus yang didapat".
the-wabbit

1

Ini bukan apa yang Anda minta, tapi saya sudah melakukan yang berikut dengan penyeimbang beban F5:

  • Hitung jumlah permintaan posting pada halaman login.
  • Tunda pengguna jika login per detik di atas batas pertama
  • Kirim pengguna ke halaman pemeliharaan jika login per detik di atas batas kedua

Karena situs web itu terkadang berada di bawah beban berat (pacuan kuda), itu membantu.


Terima kasih atas idenya, saya perlu memeriksa dengan orang AppDirector kami jika kami bisa menerapkan sesuatu yang serupa.
the-wabbit

@ syneticon-dj: jika Anda perlu memeriksa apakah Anda dapat mengimplementasikan sesuatu seperti ini (yang sebenarnya tidak menyelesaikan masalah, BTW) dan Anda tidak dapat memperbaiki aplikasi, maka Anda benar-benar berada dalam tumpukan masalah. Pada refleksi saya bisa memikirkan setidaknya 2 cara lebih lanjut untuk memecahkan masalah - tetapi keduanya secara teknis menuntut - dan diimplementasikan secara tidak benar akan membuat masalah lebih buruk daripada lebih baik. Anda membutuhkan lebih banyak bantuan daripada yang akan Anda dapatkan di sini.
symcbean

@symcbean Tidak ada yang bisa saya lakukan untuk menyelesaikan masalah ini, yaitu kurangnya kualifikasi di dalam dev dan staf pendukung vendor serta keputusan yang dibuat untuk menggunakan aplikasi ini dalam ketidaktahuannya. Jika Anda memiliki ide lain, saya akan senang mendengarnya. "Menuntut" bukan masalah asalkan tidak menambah kompleksitas dalam operasi sehari-hari.
the-wabbit

1

Masalah ini dapat diatasi baik dengan menggunakan RadWare AppDirector, dan (untuk kelengkapan) kemungkinan juga dengan menggunakan Apache mod_security sesuai temuan bagus Anda di komentar di bawah ini.

Untuk solusi AppDirector, saya percaya dimungkinkan untuk membuat dua pemetaan pertanian ke server backend yang sama. Peternakan ini dapat memiliki kriteria dan kondisi operasi berbeda yang diterapkan padanya. Satu tambak akan menjadi "default" dan yang lain akan menjawab URI: yang Anda definisikan sebagai "sesi". Yang terakhir akan mendapatkan batasan jumlah sesi yang diterimanya di load balancer.

Saya mulai sekarang akan mengganti istilah "sesi" Anda dengan "masuk" karena dua alasan:

  • Ini menghindari ambiguitas karena jelas mendefinisikan keadaan yang diinginkan di mana pengguna diautentikasi.
  • Panduan Pengguna AppDirector dan GUI mendefinisikan kembali istilah "koneksi" untuk memiliki makna untuk semua tujuan praktis yang identik dengan "sesi", lihat di bawah. Ini menambah kebingungan yang kami coba hindari.

Dimungkinkan juga untuk menampilkan halaman maaf jika peternakan "login" telah mencapai batas koneksi yang dipilih.

Sebelum membahas caranya, saya harus menyatakan dengan jelas bahwa saya tidak memiliki pengalaman pengoperasian produk AppDirector, tetapi mengelola penyeimbang muatan yang sedikit bersaing dan sedikit lebih maju setiap hari. Produk yang saya gunakan dapat melakukan skenario ini langsung. Saya telah menemukan informasi melalui Panduan Pengguna AppDirector dan dokumentasi online apa yang tersedia yang menunjukkan bahwa hal yang sama berlaku untuk AppDirector. Meskipun konsepnya serupa, terminologinya berbeda. Saya hanya melakukan tindakan ketika-dalam-roma sehubungan dengan kata-kata, berharap untuk membuatnya benar tanpa terlalu jelas bodoh.

Penghalang jalan terbesar adalah mendapatkan akses ke manual, yang tidak tersedia kecuali satu adalah pelanggan aktif. Melalui beberapa googling dimungkinkan untuk menemukan versi lama yang saya harap tidak terlalu ketinggalan zaman, saya juga menemukan beberapa artikel berbasis pengetahuan dan tautan ini: Radware AppDirector - Configuration: Basic Application .

Berikut adalah konsep solusi, sebagaimana ditafsirkan terutama melalui Panduan Pengguna:

Entri klien ke load balancer dilakukan melalui VIP yang digunakan untuk menghubungkan sesi "default" dan "sesi login". Ini dicapai melalui kebijakan L4 sesuai hal. 99 dalam Panduan Pengguna:

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

Kebijakan L4 dapat dikaitkan dengan kebijakan L7 yang digunakan untuk memilih pertanian yang cocok. Proses kebijakan L7 dijelaskan demikian dalam Panduan Pengguna hal.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."

Metode yang tersedia untuk mendefinisikan perilaku L7 diuraikan pada hal.106, di mana Anda bisa memilih metode yang cocok untuk memilih perutean ke Peternakan "masuk" daripada ke Pertanian "default":

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

Seperti yang terlihat di tautan Aplikasi Dasar , misalnya seseorang dapat membuat kebijakan L7 yang mengevaluasi pola URI untuk perutean ke berbagai peternakan. Pola URI yang dibuat '^ / login? = True' dan '^ / login' dapat dialihkan ke peternakan "login" Anda. Pola yang dibuat '^ / logout' (dan semua URI lainnya: s) juga dapat dialihkan ke tambak "default".

Ladang didefinisikan oleh Panduan Pengguna hal.121 dengan demikian: "Ladang AppDirector adalah sekelompok server jaringan yang menyediakan layanan yang sama [...] Server yang menyediakan beberapa layanan dapat digunakan di banyak tambak."

Server selanjutnya dibedakan dengan memisahkan definisi server backend menjadi dua lapisan, lapisan objek 'Fisik Server' yang mewakili alamat ip server dan lapisan objek 'Server Pertanian' yang mewakili layanan yang berjalan pada satu atau lebih Server Fisik .

Sesi yang membatasi pada sebuah tambak dapat sesuai dengan 'Panduan Pengguna AppDirector' dilakukan per setiap objek Server Tambak yang didefinisikan untuk tambak (serta melalui cara lain) di samping per objek Server Fisik. Ini dijelaskan antara tempat-tempat lain pada hal.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."

Tabel Klien dan 'Mode Biasa' -nya didefinisikan pada hal.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"

Dalam tangkapan layar jendela definisi server pada halaman Aplikasi Dasar , kotak batas koneksi server terlihat tepat di samping kotak batas bandwidth.

Jadi sedikit tergantung pada konfigurasi tetapi untuk keperluan jawaban ini, 'koneksi' sebagaimana didefinisikan melalui Tabel Klien dan 'sesi' seperti yang didefinisikan oleh Anda pada dasarnya menjadi hal yang sama. Dan batas untuk efek itu dapat dikenakan per objek server di sebuah peternakan.

Karena AppDirector membedakan antara server fisik dan server pertanian, dimungkinkan untuk menetapkan dua pemetaan server pertanian ke objek server fisik Apache Anda, yang memiliki batas koneksi rendah.

Namun, Apache juga perlu menjawab panggilan dari kedua objek server pertanian, misalnya melalui dipanggil pada dua port atau alamat ip yang terpisah - satu digunakan oleh masing-masing (server pertanian / server pertanian) kombo. Pertanyaannya kemudian, apakah Anda dapat menentukan dua titik masuk server aplikasi? yaitu apakah Anda dapat melengkapi aplikasi front end Apache Anda (/ vhost?) untuk menjawab pada dua port atau alamat IP (satu per farm)? Ini melalui sedikit tebakan karena saya tidak ingin menghabiskan terlalu banyak waktu dengan manual, tapi saya yakin Anda bisa menyelesaikan ini dengan cukup elegan ketika benar-benar melihat AppDirector GUI dan Apache.

Pengaturan batas koneksi memiliki sedikit kekhasan. Dari Server Fisik, Batas Koneksi hal.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."

Karena itu Anda perlu menetapkan Batas Koneksi yang sangat tinggi (dengan margin lebar hingga jumlah maksimum yang dimungkinkan melalui basis pengguna Anda) untuk server pertanian "default" yang tidak dibatasi, dan menetapkan Batas Koneksi untuk server pertanian "masuk" sebagai serendah yang Anda harus. Definisi server fisik perlu memiliki jumlah keduanya sebagai Batas Koneksi, sebagai prasyarat untuk mengaktifkan batas sesi yang diinginkan.


Anda juga memiliki persyaratan ini dalam pertanyaan Anda:

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

Ini disebut 'No HTTP Service Page' di Panduan Pengguna, hal.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.

Untuk bagian pemantauan, saya belum melakukan penelitian menyeluruh tetapi inilah yang saya pikirkan:

track the current number of sessions for monitoring purposes

AppDirector tampaknya memiliki MIB. Mungkin rasa sakit untuk menemukan OID yang tepat seperti biasanya, tetapi Anda mungkin dapat menggunakannya untuk alat pilihan Anda.

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

Yang satu ini membutuhkan pemikiran kreatif. Dengan asumsi AppDirector tidak menyertakan template untuk ini langsung, bagaimana tentang:

  • URI di luar tambak "login" tidak akan terpengaruh oleh batas sesi. Jadi pantau, server backend yang sama.
  • Gunakan pemeriksaan kesehatan AppDirector sebagai gantinya, mereka kemungkinan tidak akan dihitung terhadap batas sesi yang Anda berikan. Temukan cara untuk menyampaikan peringatan ke server pemantauan Anda :-)
  • Siapkan peternakan ketiga, tempat Anda lulus pemeriksaan kesehatan. Berantakan, tetapi itu akan berhasil.

1
Sejauh ini, saya telah menemukan bahwa modul mod_security2 mampu menangani sesi dengan cara yang terlihat sangat mirip dengan apa yang saya tentukan - secure.jwall.org/blog/2009/01/08/1231374852674.html . Saya akan melakukan penelitian lebih lanjut pada ide Anda tentang 2 peternakan, jika implementasi seperti itu mungkin, itu pasti akan menyederhanakan hal-hal.
the-wabbit

Tanggapan dari dukungan teknis Radware: "Dalam AD kami hanya dapat membatasi bandwidth per tambak. [...] [A] metode untuk membatasi jumlah sesi pada basis tambak saat ini tidak tersedia." Jadi mod_security itu.
the-wabbit

Ok, itu tidak terduga. Kecuali jika saya melewatkan sesuatu, saya masih berpikir menutup pertanian melalui pemeriksaan kesehatan yang gagal akan menjadi solusi yang lebih bersih. Temuan Anda pada mod_security sangat menarik.
ErikE

Mungkin meskipun dukungannya agak sempit dalam menginterpretasikan pertanyaan, tampaknya batas sesi pada tingkat server di AppDirector dimungkinkan (yang tentunya ada beberapa logika). Saya googled beberapa tautan, ini ada satu: kb.radware.com/questions/2829/…
ErikE

Artikel Radware KB tentang LinkProof - akselerator WAN. Saya tidak tahu tentang perangkat lunak apa yang sedang berjalan dan jika fasilitas serupa akan ada untuk AppDirector. BTW: Kode penanganan sesi tentu saja merupakan bagian dari set fitur AppDirector - memiliki tabel sesi yang terlihat persis seperti yang saya harapkan. Namun ternyata, tidak ada cara untuk memaksakan batasan jumlah sesi - hanya pada koneksi. Yang paling bisa saya dapatkan dari itu adalah membatasi jumlah hit pada halaman tertentu (misalnya halaman login) per unit waktu sebagai "yang lain" yang disarankan Eric.
the-wabbit

0

Jika AppDirector tidak dapat membantu Anda, inilah pendekatan lain yang akan membutuhkan sedikit pengkodean. Saya akan mengatasi masalah sebagai berikut:

  • Dalam satu lingkaran, terus membaca file log apache (dan buka kembali pada logrotate)
  • Ketika seorang pengguna mengunjungi halaman mana pun (tidak hanya login), tambahkan mereka ke daftar putih iptables
  • Saat pengguna keluar, atau setelah tidak aktif (jadi tetap gunakan timer untuk sesi aktif!), Hapus mereka dari daftar putih
  • Jika daftar putih penuh, arahkan semua lalu lintas yang tidak masuk daftar putih ke port khusus
  • Jalankan vhost sederhana di port itu dengan kesalahan khusus Anda

Membuat grafik jumlah sesi menjadi sesederhana seperti menggambarkan panjang rantai iptables. Server pemantauan bisa saja selalu masuk daftar putih.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.