Hosting multi-situs - kerentanan penting yang terlewatkan untuk mengamankan situs satu sama lain?

EDIT # 2 23 Juli 2015: Mencari jawaban baru yang mengidentifikasi item keamanan penting yang terlewat dalam pengaturan di bawah ini atau dapat memberikan alasan untuk meyakini semuanya tercakup.

EDIT # 3 29 Juli 2015: Saya terutama mencari kemungkinan kesalahan konfigurasi seperti secara tidak sengaja mengizinkan sesuatu yang dapat dieksploitasi untuk menghindari pembatasan keamanan atau lebih buruk lagi tetapi membiarkan sesuatu terbuka lebar.

Ini adalah pengaturan multi-situs / shared hosting dan kami ingin menggunakan contoh Apache bersama (yaitu berjalan di bawah satu akun pengguna) tetapi dengan PHP / CGI berjalan sebagai pengguna setiap situs web untuk memastikan tidak ada situs yang dapat mengakses file situs lain, dan kami ingin pastikan tidak ada yang terlewatkan (mis. jika kita tidak tahu tentang pencegahan serangan symlink).

Inilah yang saya miliki sejauh ini:

• Pastikan skrip PHP dijalankan sebagai akun dan grup pengguna Linux situs web, dan dapat dipenjara (seperti menggunakan CageFS) atau setidaknya dibatasi dengan benar menggunakan izin sistem file Linux.
• Gunakan suexec untuk memastikan bahwa skrip CGI tidak dapat dijalankan sebagai pengguna Apache.
• Jika membutuhkan sisi server termasuk dukungan (seperti dalam file shtml), gunakan Options IncludesNOEXECuntuk mencegah CGI agar tidak dapat dijalankan ketika Anda tidak mengharapkannya (meskipun ini seharusnya tidak menjadi masalah jika menggunakan suexec).
• Memiliki perlindungan serangan symlink di tempat sehingga seorang hacker tidak bisa menipu Apache untuk menyajikan file situs web lain sebagai plaintext dan mengungkapkan informasi yang dapat dieksploitasi seperti kata sandi DB.
• Konfigurasikan AllowOverride/ AllowOverrideListhanya membolehkan arahan yang tidak dapat dieksploitasi oleh peretas. Saya pikir ini kurang menjadi perhatian jika item di atas dilakukan dengan benar.

Saya akan menggunakan MPM ITK jika tidak terlalu lambat dan tidak berjalan sebagai root, tetapi kami secara khusus ingin menggunakan Apache bersama namun memastikan itu dilakukan dengan aman.

Saya menemukan http://httpd.apache.org/docs/2.4/misc/security_tips.html , tetapi itu tidak komprehensif pada topik ini.

Jika Anda tahu, kami berencana menggunakan CloudLinux dengan CageFS dan mod_lsapi.

Apakah ada hal lain yang harus dilakukan atau diketahui?

EDIT 20 Juli 2015: Orang-orang telah mengirimkan beberapa solusi alternatif yang baik yang bernilai secara umum, tetapi harap dicatat bahwa pertanyaan ini hanya ditujukan untuk keamanan pengaturan Apache bersama. Secara khusus adakah sesuatu yang tidak dicakup di atas yang dapat membuat suatu situs mengakses file situs lain atau entah bagaimana membahayakan situs lain?

Terima kasih!

Saya sepenuhnya setuju dengan item yang Anda miliki sejauh ini.

Saya dulu menjalankan setup multi-user seperti itu beberapa tahun yang lalu dan pada dasarnya saya menemukan trade-off yang sama: mod_php cepat (sebagian karena semuanya berjalan di dalam proses yang sama) dan suexec lambat tapi aman (karena setiap permintaan membuat garpu baru proses). Saya menggunakan suexec, karena isolasi pengguna diperlukan.

Saat ini ada opsi ketiga yang dapat Anda pertimbangkan: berikan setiap pengguna daemon php-fpm mereka sendiri. Apakah ini layak tergantung pada jumlah pengguna, karena setiap dari mereka harus mendapatkan setidaknya satu proses php-fpm menggunakan akun pengguna mereka (daemon kemudian menggunakan mekanisme seperti prefork untuk mengukur permintaan, sehingga jumlah proses dan penggunaan memori mereka mungkin menjadi faktor pembatas). Anda juga akan memerlukan beberapa generasi konfigurasi otomatis, tetapi itu bisa dilakukan dengan beberapa skrip shell.

Saya belum pernah menggunakan metode itu di lingkungan yang besar tetapi IMHO itu adalah solusi yang baik untuk memberikan kinerja situs web PHP yang baik sementara masih mengisolasi pengguna pada tingkat proses.

Semua yang Anda miliki sejauh ini tampaknya dipikirkan dengan baik. Satu-satunya hal yang bisa saya lihat sebagai masalah adalah kenyataan bahwa sebagian besar eksploit berusaha mendapatkan akses root dengan satu atau lain cara. Jadi, bahkan jika setiap situs dan proses serta skripnya yang sesuai dipenjara dengan benar dan semuanya memiliki pengguna sendiri dan izin peretas dengan root tidak peduli, mereka hanya akan menghindari semua yang Anda siapkan.

Saran saya adalah menggunakan beberapa jenis perangkat lunak VM (VMware, VirtualBox, Qemu, dll) untuk memberikan masing-masing situs itu OS jailnya sendiri. Ini memungkinkan Anda, sebagai admin sistem, untuk tidak khawatir tentang satu situs yang disusupi. Jika seorang hacker mendapatkan root dengan mengeksploitasi php (atau perangkat lunak lain apa pun) pada VM situs, cukup jeda VM dan potong kemudian, terapkan perbaikan, atau putar kembali ke keadaan tidak terputus. Ini juga memungkinkan admin situs untuk menerapkan perangkat lunak atau pengaturan keamanan khusus untuk lingkungan situs spesifik mereka (yang mungkin merusak situs lain).

Satu-satunya batasan untuk ini adalah perangkat keras Anda tetapi dengan server yang layak dan ekstensi kernel yang benar mudah untuk ditangani. Saya telah berhasil menjalankan jenis pengaturan ini pada Linode, memberikan Host dan Guest sangat jarang. Jika Anda merasa nyaman dengan baris perintah yang saya anggap Anda adalah Anda seharusnya tidak memiliki masalah.

Jenis pengaturan ini mengurangi jumlah vektor serangan yang harus Anda monitor dan memungkinkan Anda untuk fokus pada keamanan Mesin Host dan menangani segala sesuatu yang lain di situs demi situs.

Saya menyarankan agar setiap situs dijalankan di bawah daemon Apache sendiri, dan chrooting Apache. Semua fungsi sistem php akan gagal karena lingkungan chroot Apache tidak akan memiliki akses ke / bin / sh. Ini juga berarti bahwa fungsi mail () php juga tidak akan berfungsi, tetapi jika Anda menggunakan penyedia email eksternal untuk mengirim email dari aplikasi email Anda, maka ini seharusnya tidak menjadi masalah bagi Anda.

SELinux mungkin bisa membantu mod_selinux. Howto cepat ditampilkan di sini:

Bagaimana saya bisa menggunakan SELinux untuk membatasi skrip PHP?

Karena instruksinya sedikit bertanggal, saya memeriksa apakah ini bekerja di RHEL 7.1:

Saya telah menggunakan versi Fedora 19 dan dikompilasi dengan mengejek terhadap RHEL 7.1 + EPEL.

YMMV jika Anda menggunakan kapal tiruan konfigurasi epel dasar dengan:

[mockbuild@fedora mod_selinux]$ mock -r rhel-7-x86_64 --rebuild \
    mod_selinux-2.4.3-2.fc19.src.rpm

Mutakhirkan sistem target Anda terlebih dahulu untuk memastikan bahwa selinux-policyitu terkini.

Pasang di kotak target (atau masukkan cermin lokal Anda terlebih dahulu):

yum localinstall mod_selinux-2.4.3-2.el7.x86_64.rpm

Sekarang, Anda harus menetapkan setiap host virtual dalam kategori apache. Ini dilakukan dengan menambahkan garis seperti pada contoh di bawah ini yang disebut selinuxDomainVal.

<VirtualHost *:80>
    DocumentRoot /var/www/vhosts/host1
    ServerName host1.virtual
    selinuxDomainVal *:s0:c0
</VirtualHost>

<VirtualHost *:80>
    DocumentRoot /var/www/vhosts/host2
    ServerName host2.virtual
    selinuxDomainVal *:s0:c1 
</VirtualHost>

Selanjutnya, dalam root dokumen untuk setiap host, beri label ulang root dokumen mereka ke kategori yang sama dengan yang berlabel dalam konfigurasi httpd.

chcon -R -l s0:c0 /var/www/vhosts/host1
chcon -R -l s0:c1 /var/www/vhosts/host2

Jika Anda ingin membuat pelabelan merasa terhormat jika Anda melakukan relabel sistem, Anda sebaiknya memperbarui kebijakan lokal juga!

semanage fcontext -a -t httpd_sys_content_t -r s0-s0:c0 '/var/www/vhosts/host1(/.*)?' 
semanage fcontext -a -t httpd_sys_content_t -r s0-s0:c1 '/var/www/vhosts/host2(/.*)?'

Ada banyak jawaban teknis yang baik sudah disediakan (silakan juga lihat di sini: https://security.stackexchange.com/q/77/52572 dan Kiat untuk Mengamankan Server LAMP ), tetapi saya masih ingin menyebutkan di sini poin penting (dari sudut pandang lain) tentang keamanan: keamanan adalah suatu proses . Saya yakin Anda sudah mempertimbangkan hal ini, tetapi saya masih berharap itu bisa berguna (juga untuk pembaca lain) untuk kadang-kadang memikirkan kembali.

Misalnya, dalam pertanyaan Anda, Anda berkonsentrasi terutama pada langkah-langkah teknis: "pertanyaan ini ditargetkan hanya mengenai keamanan pengaturan Apache yang dibagikan. Secara khusus, apakah ada langkah-langkah keamanan yang penting untuk diambil tetapi tidak ada dalam daftar di atas saat menjalankan dibagikan Apache dan PHP. "

Hampir semua jawaban di sini dan pada 2 pertanyaan lain yang saya sebutkan juga tampaknya murni teknis (kecuali rekomendasi untuk tetap diperbarui). Dan dari sudut pandang saya ini bisa membuat beberapa pembaca kesan yang menyesatkan, bahwa jika Anda mengkonfigurasi server Anda sesuai dengan praktik terbaik sekali, maka Anda tetap aman selamanya. Jadi tolong jangan lupa tentang poin yang saya lewatkan dalam jawaban:

1. Pertama-tama, jangan lupa, bahwa keamanan adalah proses dan, khususnya, tentang siklus "Plan-Do-Check-Act", seperti yang direkomendasikan oleh banyak standar, termasuk ISO 27001 ( http://www.isaca.org/ Jurnal / arsip / 2011 / Volume-4 / Halaman / Perencanaan-untuk-dan-Pelaksana-ISO27001.aspx ). Pada dasarnya, ini berarti Anda perlu merevisi langkah-langkah keamanan Anda, memperbarui dan mengujinya secara teratur .

2. Perbarui sistem Anda secara teratur. Ini tidak akan membantu melawan serangan yang ditargetkan menggunakan kerentanan zero-day, tetapi itu akan membantu terhadap hampir semua serangan otomatis.

3. Pantau sistem Anda. Saya benar-benar melewatkan jawaban ini. Dari sudut pandang saya, sangat penting untuk diberitahukan sedini mungkin tentang beberapa masalah dengan sistem Anda.

   Inilah yang dikatakan statistik tentang hal itu: "Rata-rata waktu dari infiltrasi ke penemuan adalah 173,5 hari" ( http://www.triumfant.com/detection.html ), "205 rata-rata jumlah hari sebelum deteksi" ( https: // www2 .fireeye.com / rs / fireye / images / rpt-m-tren-2015.pdf ). Dan saya berharap angka-angka ini bukan yang kita semua inginkan.

   Ada banyak solusi (termasuk gratis) tidak hanya untuk memantau keadaan layanan (seperti Nagios), tetapi juga sistem deteksi intrusi (OSSEC, Snort) dan sistem SIEM (OSSIM, Splunk). Jika menjadi terlalu rumit, Anda setidaknya dapat mengaktifkan sesuatu seperti 'fail2ban' dan / atau meneruskan log Anda ke server syslog yang terpisah, dan memiliki notifikasi email tentang peristiwa penting.

   Sekali lagi, poin terpenting di sini bukanlah sistem pemantauan yang Anda pilih, yang paling penting adalah Anda memiliki beberapa pemantauan dan merevisinya secara teratur sesuai dengan siklus "Plan-Do-Check-Act" Anda .

4. Waspadai kerentanan. Sama seperti pemantauan. Berlanggananlah ke beberapa daftar kerentanan untuk diberi tahu, ketika beberapa kerentanan kritis ditemukan untuk Apache atau layanan lain yang penting untuk pengaturan Anda. Tujuannya adalah untuk diberitahu tentang hal-hal paling penting yang muncul sebelum pembaruan terencana berikutnya.

5. Siapkan rencana apa yang harus dilakukan jika terjadi insiden (dan perbarui dan revisi secara teratur sesuai dengan siklus "Plan-Do-Check-Act" Anda). Jika Anda bertanya tentang konfigurasi aman, itu berarti keamanan sistem Anda menjadi penting bagi Anda. Namun, apa yang harus Anda lakukan jika sistem Anda diretas terlepas dari semua tindakan keamanan? Sekali lagi, saya tidak bermaksud hanya tindakan teknis di sini seperti "instal ulang OS": Di mana Anda harus melaporkan kecelakaan sesuai dengan hukum yang berlaku? Apakah Anda diizinkan mematikan / memutuskan server Anda segera (berapa biayanya untuk perusahaan Anda)? Siapa yang harus dihubungi jika penanggung jawab utama sedang berlibur / sakit?

6. Memiliki server cadangan, arsip, dan / atau pengganti / replikasi. Keamanan juga berarti ketersediaan layanan Anda. Periksa cadangan / arsip / replikasi Anda secara teratur dan juga uji prosedur pengembalian secara teratur.

7. Pengujian penetrasi? (lagi, lihat siklus "Plan-Do-Check-Act" :) Jika terasa terlalu banyak, Anda setidaknya bisa mencoba beberapa alat online gratis, yang memindai layanan web Anda untuk masalah malware dan keamanan.

Kasing penggunaan Anda ideal untuk kontainer buruh pelabuhan.

Setiap kontainer dapat mewakili pelanggan atau klien, dengan ID pengguna unik yang ditetapkan untuk setiap grup wadah Apache sebagai keamanan tambahan. Kuncinya adalah untuk menjatuhkan hak root pada awal wadah, sebelum memulai tumpukan apache Anda. Setiap pelanggan mendapatkan layanan DB mereka sendiri dengan kata sandi unik mereka sendiri, tanpa pusing berdiri puluhan mesin virtual, masing-masing membutuhkan kernel kepingan salju khusus mereka dan overhead lainnya. Bagaimanapun, di jantung buruh pelabuhan adalah chroot. Dikelola dengan benar, saya akan mengambil alih kluster virtual khas setiap hari.

Sudah banyak saran bagus di sini. Ada hal-hal yang terlewatkan dalam diskusi sejauh ini.

Perhatikan proses di luar yang dijalankan sebagai bagian dari melayani halaman web. yaitu memastikan bahwa semua pekerjaan cron Anda yang menyentuh data yang tidak dipercaya berjalan sebagai pengguna yang sesuai dan di penjara yang sesuai, apakah pekerjaan itu ditentukan oleh pengguna atau tidak.

Dalam pengalaman saya hal-hal seperti analisis log, ketika disediakan oleh layanan hosting, dijalankan sebagai root hampir sesering mungkin, dan perangkat lunak analisis log tidak diberikan audit keamanan sebanyak yang kita inginkan. Melakukan ini dengan baik agak sulit, dan tergantung pengaturan. Di satu sisi, Anda tidak ingin proses apache yang dimiliki root (yaitu proses induk) menulis ke direktori apa pun yang dapat dikompromikan oleh pengguna. Itu mungkin berarti tidak menulis ke penjara secara langsung. Di sisi lain Anda perlu membuat file-file itu tersedia untuk proses di penjara untuk analisis, dan Anda ingin agar sedekat mungkin dengan waktu nyata. Jika Anda dapat memberikan akses penjara Anda ke mount hanya-baca dari sistem file dengan log, itu harus baik.

Aplikasi PHP biasanya tidak menyajikan file statis mereka sendiri, dan jika Anda memiliki proses apache bersama maka saya menduga bahwa proses apache Anda membaca hal-hal langsung dari penjara dari lingkungan host? Jika demikian, maka itu membuka berbagai kekhawatiran.

.htaccessFile-file itu jelas, di mana Anda harus sangat berhati-hati dengan apa yang Anda izinkan. Banyak atau bahkan sebagian besar aplikasi php sangat bergantung pada pengaturan file .htaccess yang mungkin tidak dapat Anda izinkan tanpa merongrong skema yang Anda rencanakan.

Yang kurang jelas adalah bagaimana apache memutuskan apa itu file statis. mis. Apa fungsinya dengan file *.php.gifatau *.php.en? Jika mekanisme ini atau yang lain mengelabui diskriminasi tentang apa itu file statis, mungkinkah apache menjalankan php sama sekali dari luar penjara? Saya membuat server web ringan terpisah untuk konten statis, yang tidak dikonfigurasikan dengan modul apa pun untuk mengeksekusi konten dinamis, dan meminta penyeimbang beban memutuskan permintaan mana yang akan dikirim ke server statis dan yang ke server dinamis.

Mengenai saran Docker Stefan, dimungkinkan untuk memiliki server web tunggal yang duduk di luar wadah, dan yang berbicara dengan daemon php di setiap wadah untuk konten dinamis, sementara juga memiliki server web kedua, yang duduk di wadah buruh pelabuhan, dan yang berbagi volume masing-masing menggunakan untuk konten mereka, dan dengan demikian dapat melayani konten statis, yang sama seperti pada paragraf sebelumnya. Saya memuji buruh pelabuhan di antara berbagai pendekatan jenis penjara, tetapi dengan pendekatan jenis ini atau lainnya, Anda akan memiliki banyak masalah lain untuk diselesaikan. Bagaimana cara kerja unggah file? Apakah Anda meletakkan daemon transfer file di setiap wadah? Apakah Anda mengambil pendekatan berbasis gaya PAAS git? Bagaimana Anda membuat log yang dihasilkan di dalam wadah dapat diakses, dan menggulungnya? Bagaimana Anda mengelola dan menjalankan pekerjaan cron? Apakah Anda akan memberikan para pengguna semacam akses shell, dan jika demikian, apakah itu daemon lain di dalam wadah? dll, dll.

Hal pertama yang saya tidak lihat adalah manajemen proses sehingga satu proses tidak dapat kelaparan proses CPU atau RAM lain (atau I / O dalam hal ini, meskipun sistem file Anda mungkin dirancang untuk mencegahnya). Salah satu keuntungan utama dari pendekatan "penampung" pada instance PHP Anda vs. mencoba menjalankan semuanya pada satu gambar "OS" adalah bahwa Anda dapat membatasi pemanfaatan sumber daya dengan lebih baik. Saya tahu itu bukan desain Anda, tapi itu sesuatu yang perlu dipertimbangkan.

Bagaimanapun, kembali ke kasus penggunaan PHP yang berjalan di belakang Apache pada dasarnya berfungsi sebagai proxy. suexec tidak mencegah sesuatu berjalan sebagai pengguna apache - ia menyediakan kemampuan untuk berjalan sebagai pengguna lain. Jadi satu kekhawatiran akan memastikan bahwa semuanya dilakukan dengan benar - halaman dokumen untuk itu menyebutkan potensi bahaya: https://httpd.apache.org/docs/2.2/suexec.html . Jadi, Anda tahu, sebutir garam dan semua itu.

Dari sudut pandang keamanan dapat membantu untuk memiliki satu set terbatas binari pengguna untuk bekerja dengan (yang cagefs persediaan), terutama jika mereka dikompilasi berbeda atau terhadap perpustakaan yang berbeda (misalnya satu yang tidak termasuk kemampuan yang tidak diinginkan) , tetapi yang bahayanya adalah bahwa pada saat itu Anda tidak lagi mengikuti distribusi yang dikenal untuk pembaruan, Anda mengikuti distribusi yang berbeda (cagefs) untuk instalasi PHP Anda (setidaknya sehubungan dengan alat ruang pengguna). Meskipun karena Anda mungkin sudah mengikuti distribusi tertentu dengan cloudlinux itu risiko tambahan, belum tentu menarik dengan sendirinya.

Saya akan meninggalkan AllowOverride di tempat yang mungkin Anda tuju. Gagasan inti di balik pertahanan secara mendalam adalah untuk tidak bergantung pada satu lapisan tunggal untuk melindungi seluruh tumpukan Anda. Selalu berasumsi ada yang salah. Mitigasi ketika itu terjadi. Ulangi sampai Anda telah meringankannya sebaik mungkin walaupun Anda hanya memiliki satu pagar di depan situs Anda.

Manajemen log akan menjadi kunci. Dengan beberapa layanan yang berjalan dalam sistem file yang terisolasi, mengintegrasikan aktivitas untuk berkorelasi ketika ada masalah bisa menjadi masalah kecil jika Anda belum mengaturnya sejak awal.

Itu dump otakku. Semoga ada sesuatu yang samar-samar berguna di sana. :)