RPC melalui Rekomendasi Penyebaran HTTP

Bagian ini mendokumentasikan praktik terbaik dan konfigurasi penyebaran yang direkomendasikan untuk mencapai keamanan dan performa maksimum saat menggunakan RPC melalui HTTP. Berbagai konfigurasi yang ditemukan di sini berlaku melakukan organisasi yang berbeda berdasarkan berbagai persyaratan ukuran, anggaran, dan keamanan. Setiap konfigurasi juga menyediakan pertimbangan penyebaran yang berguna dalam menentukan mana yang terbaik untuk skenario tertentu.

Untuk informasi mengenai RPC volume tinggi melalui skenario HTTP, silakan lihat Microsoft RPC Load Balancing.

Rekomendasi berikut berlaku untuk semua konfigurasi:

• Gunakan versi Windows yang mendukung RPC melalui HTTP v2.
• Letakkan IIS pada komputer yang menjalankan Proksi RPC dalam mode IIS 6.0.
• Larang akses anonim ke direktori virtual Proksi RPC.
• Jangan pernah mengaktifkan kunci registri AllowAnonymous.
• Buat RPC Anda melalui klien HTTP menggunakan CertificateSubjectField (lihat RpcBindingSetAuthInfoEx untuk informasi selengkapnya) untuk memverifikasi bahwa Proksi RPC yang Anda sambungkan adalah Proksi RPC yang Anda harapkan.
• Konfigurasikan kunci registri ValidPorts agar hanya berisi komputer yang akan disambungkan oleh RPC melalui klien HTTP.
• Jangan gunakan kartubebas di kunci ValidPorts ; melakukannya dapat menghemat waktu, tetapi mesin yang benar-benar tidak terduga mungkin juga sesuai dengan kartubebas.
• Gunakan SSL pada RPC melalui klien HTTP. Jika pedoman yang ditetapkan di bagian ini diikuti, RPC melalui klien HTTP tidak akan dapat terhubung tanpa menggunakan SSL.
• Konfigurasikan RPC melalui klien HTTP untuk menggunakan Enkripsi RPC selain menggunakan SSL. Jika RPC melalui klien HTTP tidak dapat mencapai KDC, itu hanya dapat menggunakan Negosiasi dan NTLM.
• Konfigurasikan komputer klien untuk menggunakan NTLMv2. Atur kunci registri LMCompatibilityLevel ke 2 atau lebih tinggi. Lihat msdn.microsoft.com untuk informasi selengkapnya tentang kunci LMCompatibilityLevel .
• Jalankan farm web komputer Proksi RPC dengan konfigurasi yang diuraikan di atas.
• Sebarkan firewall antara Internet dan Proksi RPC.
• Untuk performa optimal, konfigurasikan IIS untuk mengirim respons singkat untuk kode kesalahan yang tidak berhasil. Karena konsumen respons IIS adalah proses otomatis, tidak perlu penjelasan ramah pengguna untuk dikirim ke klien; mereka hanya akan diabaikan oleh RPC melalui klien HTTP.

Tujuan dasar Proksi RPC dari perspektif keamanan, performa, dan pengelolaan adalah sebagai berikut:

• Berikan satu titik masuk untuk RPC melalui lalu lintas HTTP ke jaringan server. Memiliki satu titik masuk untuk RPC melalui lalu lintas HTTP ke jaringan server memiliki dua manfaat utama. Pertama, karena Proksi RPC menghadapi Internet, sebagian besar organisasi mengisolasi komputer tersebut dalam jaringan khusus yang disebut jaringan perimeter yang tidak tepercaya yang terpisah dari jaringan organisasi normal. Server dalam jaringan perimeter yang tidak tepercaya dikelola dengan sangat hati-hati, dikonfigurasi, dan dipantau untuk dapat menahan serangan dari Internet. Semakin sedikit mesin dalam jaringan perimeter yang tidak tepercaya, semakin mudah untuk mengonfigurasi, mengelola, memantau, dan menjaganya tetap aman. Kedua, karena satu Web Farm dengan Proksi RPC yang diinstal dapat melayani sejumlah RPC melalui Server HTTP yang berada di jaringan perusahaan, sangat masuk akal untuk memisahkan Proksi RPC dari RPC melalui Server HTTP dan memiliki Proksi RPC yang berada di jaringan perimeter yang tidak tepercaya. Jika Proksi RPC berada di komputer yang sama dengan RPC melalui SERVER HTTP, organisasi akan dipaksa untuk menempatkan semua server ujung belakang mereka ke dalam jaringan perimeter yang tidak tepercaya, yang akan membuatnya jauh lebih sulit untuk menjaga jaringan perimeter yang tidak tepercaya tetap aman. Memisahkan peran Proksi RPC dan RPC melalui server HTTP membantu organisasi menjaga jumlah komputer dalam jaringan perimeter yang tidak tepercaya dapat dikelola dan oleh karena itu, lebih aman.
• Berfungsi sebagai sekering keamanan untuk jaringan server. Proksi RPC dirancang sebagai sekering yang dapat dibuang untuk jaringan server - jika ada yang salah pada Proksi RPC, itu hanya keluar dan dengan demikian melindungi RPC nyata melalui server HTTP. Jika praktik terbaik yang diuraikan di bagian ini telah diikuti sejauh ini, RPC melalui lalu lintas HTTP dienkripsi dengan enkripsi RPC selain SSL. Enkripsi RPC itu sendiri adalah antara klien dan server, bukan antara klien dan proksi. Ini berarti proksi tidak memahami dan tidak dapat mendekripsi lalu lintas RPC yang diterimanya. Ini hanya memahami beberapa urutan kontrol yang dikirim ke dalamnya oleh klien yang berurusan dengan pembentukan koneksi, kontrol aliran, dan detail penerowongan lainnya. Ini tidak memiliki akses ke data yang dikirim klien RPC melalui HTTP ke server. Selain itu, RPC melalui klien HTTP harus mengautentikasi secara independen ke Proksi RPC dan RPC melalui server HTTP. Ini memberikan pertahanan secara mendalam. Jika komputer Proksi RPC menjadi disusupi, karena beberapa kesalahan konfigurasi atau pelanggaran keamanan semacam itu, data yang melewatinya masih aman dari perubahan. Penyerang yang akan mendapatkan kontrol dari Proksi RPC paling banyak dapat mengganggu lalu lintas, tetapi tidak membacanya atau mengubahnya. Di sinilah peran sekering Proksi RPC mulai berperan - itu dapat dibuang tanpa keamanan RPC melalui lalu lintas HTTP yang disusupi.
• Distribusikan beberapa pemeriksaan akses dan pekerjaan dekripsi di antara beberapa komputer yang menjalankan Proksi RPC di Web Farm. Dengan berfungsi dengan baik di Web Farm, Proksi RPC memungkinkan organisasi untuk membongkar dekripsi SSL dan beberapa pemeriksaan akses, sehingga membebaskan lebih banyak kapasitas di server ujung belakang untuk diproses. Menggunakan Web Farm mesin Proksi RPC juga memungkinkan organisasi untuk meningkatkan kemampuannya untuk menahan serangan Denial of Service (DoS) dengan meningkatkan kapasitas di server ujung depannya.

Dalam pedoman yang ditetapkan sejauh ini, organisasi masih memiliki pilihan. Setiap organisasi memiliki pilihan dan kompromi antara ketidaknyamanan, keamanan, dan biaya pengguna:

• Gunakan Autentikasi Dasar atau Autentikasi Terintegrasi Windows untuk mengautentikasi ke Proksi RPC? RPC melalui HTTP saat ini hanya mendukung NTLM - tidak mendukung Kerberos. Selain itu, jika ada Proksi HTTP atau firewall antara RPC melalui klien HTTP dan Proksi RPC yang menyisipkan melalui pragma di header HTTP, autentikasi NTLM tidak akan berfungsi. Ketika itu tidak terjadi, organisasi dapat memilih antara autentikasi Dasar dan NTLM. Keuntungan dari autentikasi Dasar adalah lebih cepat dan sederhana, dan karenanya menawarkan lebih sedikit kesempatan untuk penolakan serangan layanan. Tetapi NTLM lebih aman. Bergantung pada prioritas organisasi, organisasi dapat memilih Dasar, NTLM, atau memungkinkan penggunanya untuk memilih di antara keduanya. Jika hanya satu yang dipilih, yang terbaik adalah mematikan yang lain dari direktori virtual Proksi RPC untuk mengurangi risiko serangan.
• Gunakan set kredensial yang sama untuk Proksi RPC dan RPC melalui Server HTTP, atau gunakan kredensial yang berbeda untuk masing-masing kredensial? Tradeoff untuk keputusan ini adalah antara kenyamanan dan keamanan pengguna. Beberapa pengguna ingin memasukkan beberapa kredensial. Namun, jika pelanggaran keamanan terjadi di jaringan perimeter yang tidak tepercaya, memiliki serangkaian kredensial terpisah untuk Proksi RPC dan RPC melalui Server HTTP memberikan perlindungan tambahan. Perhatikan bahwa jika kredensial terpisah digunakan, dan satu set kredensial adalah kredensial domain pengguna, disarankan untuk menggunakan kredensial domain pengguna untuk RPC melalui Server HTTP dan bukan untuk Proksi RPC.