Jawaban:
Pertama-tama, ketahuilah bahwa kemampuan skrip apa pun di Apache (php, cgi, ruby, ...) adalah potensi yang setara dengan akun shell dengan hak istimewa pengguna yang menjalankan skrip.
Jika server dibagikan dengan banyak pengguna, Anda mungkin ingin berpikir untuk menggunakan suexec (- atau ITK MPM - Disarankan oleh David Schmitt ) sehingga tidak setiap skrip berjalan sebagai pengguna apache yang sama.
Virtualisasi atau chroot apache, sehingga kompromi apa pun setidaknya agak terkandung dalam lapisan keamanan tambahan. Ketahuilah bahwa ketika Anda chroot apache, pemeliharaan mungkin menjadi lebih sulit, karena Anda akhirnya memindahkan pustaka ke penjara, dll. Jika Anda menggunakan FreeBSD, Anda dapat menggunakan jail, yang lebih mudah dipertahankan, karena Anda bisa menginstal apache dari port, dan jalankan portaudit dari dalamnya, tanpa harus khawatir tentang dependensi pustaka dan memindahkan file secara manual, yang selalu menjadi kekacauan yang buruk. Dengan penjara BSD, Anda cukup menggunakan sistem manajemen paket (port). (Pada GNU / Linux Anda juga dapat menggunakan VServer untuk virtualisasi. - Disarankan oleh David Schmitt )
(tentu saja) Bersaing dengan pembaruan dan tambalan, tidak hanya untuk Apache, tetapi juga PHP, ruby, perl, dll ... jangan hanya mempercayai OS Anda untuk memberi Anda semua pembaruan juga. Beberapa distro sangat lambat dengan tambalannya. Batasi waktu paparan hingga kerentanan 0 hari sebanyak mungkin. Menempel umpan milw0rm di pembaca RSS Anda, berlangganan milis insecure.org , dll ... Tidak hanya itu akan membantu Anda mempelajari tentang kerentanan sebelum OS Anda berkeliling untuk merilis sebuah tambalan, Anda juga akan belajar tentang kerentanan di php tertentu aplikasi cms misalnya, yang mungkin bahkan tidak dikelola atau ditambal oleh OS Anda sama sekali.
Gunakan sesuatu seperti tripwire / ajudan, audit, atau mtree (di BSD) untuk melacak perubahan pada sistem file Anda. Yang ini sangat penting. Mintalah setiap perubahan dikirimkan kepada Anda secara teratur, tinjau secara manual, setiap hari. Jika ada perubahan file yang seharusnya tidak berubah, selidiki mengapa. Jika beberapa javascript berbahaya entah bagaimana dimasukkan ke halaman Anda melalui metode apa pun, Anda AKAN menangkapnya dengan cara ini. Ini tidak hanya menyelamatkan server Anda, tetapi juga pengguna Anda, karena halaman web Anda sendiri dapat disalahgunakan untuk menginfeksi pengunjung Anda. (Ini adalah taktik yang sangat umum, penyerang sering tidak peduli dengan server Anda, mereka hanya ingin menginfeksi sebanyak mungkin pengunjung Anda sampai ditemukan. Penyerang ini bahkan tidak repot-repot menyembunyikan jejak mereka biasanya. Menangkap kompromi seperti ini secepat mungkin sangat penting.)
Menggunakan hal-hal seperti suhosin untuk melindungi bantuan php. Tetapi juga belajar memahaminya, atur konfigurasi untuk parameter yang diharapkan aplikasi Anda.
Menggunakan patch kernel seperti PaX dapat membantu melindungi Anda dari banyak kerentanan buffer overflow. Bahkan jika perangkat lunak Anda rentan. (Ini tidak membuat Anda kebal, itu hanya lapisan lain, minor.)
Jangan terlalu percaya diri saat menggunakan beberapa alat keamanan. Pahami alat yang Anda gunakan, dan gunakan akal sehat. Baca, pelajari, ikuti terus sebanyak yang Anda bisa.
Pertimbangkan untuk menggunakan kontrol akses wajib (mis: SELinux ). Ini memungkinkan Anda menentukan, untuk setiap aplikasi, apa yang diizinkan untuk dilakukan, dengan sangat terperinci. File apa yang diizinkan untuk diakses. Apa panggilan kernel itu diizinkan untuk membuat, dll. Ini adalah proses yang sangat terlibat dan membutuhkan banyak pemahaman. Beberapa distro menyediakan kebijakan SELinux yang sudah dibuat sebelumnya untuk paket mereka (mis .: Gentoo ). Saran ini semacam kontradiksi dengan yang di bawah ini, namun tetap valid.
Buat hal-hal sederhana. Strategi keamanan yang kompleks dapat merugikan Anda.
Di Apache, atur aturan default yang sangat ketat (Opsi Tidak Ada, Tolak dari semua, dll ...) dan ganti sesuai kebutuhan untuk VirtualHost tertentu.
Tolak akses ke semua file dot (yang juga segera mencakup file .htaccess)
Selalu gunakan https di mana saja ada otentikasi kata sandi.
Firewall harus menjadi kebijakan penolakan-oleh-standar. Buat beberapa aturan khusus di firewall Anda untuk mencatat lalu lintas tertentu.
Siapkan skrip penguraian log untuk memindai anomali log Anda. ( suite IDS awal dapat melakukan ini, tetapi jujur, saya sarankan Anda membangun skrip sendiri dari waktu ke waktu, karena ini akan membantu Anda memahami alat dan aturan Anda sendiri dengan lebih baik.)
Minta server mengirimkan laporan harian kepada Anda tentang pengguna yang terakhir kali masuk, koneksi aktif, bandwidth yang digunakan, dll ...
Minta pemindaian cron untuk binari suid, file dunia yang dapat ditulisi, dan hal-hal seperti itu, dan minta mereka mengirimkannya kepada Anda.
Untuk setiap hal yang Anda atur yang dikirimkan kepada Anda, Anda harus membuat daftar pengecualian dari waktu ke waktu. (folder untuk mengabaikan perubahan filesystem aktif, 777 file untuk dibolehkan, suid binari untuk diizinkan). Penting bahwa Anda hanya diberi tahu tentang hal-hal yang seharusnya tidak terjadi. Jika Anda menerima email setiap hari dengan hal-hal sepele, Anda akan mulai mengabaikannya, dan itu akan menjadi sia-sia.
Memiliki strategi cadangan berlebihan yang solid dan berlapis. Dan jangan hanya berasumsi bahwa membuat gambar atau salinan dari segalanya berfungsi. Misalnya, jika MySQL sedang menulis untuk tabel selama cadangan Anda, file biner MySQL Anda mungkin rusak ketika Anda memulihkan cadangan Anda. Jadi Anda akan memerlukan cron yang mysqldump adalah basis data Anda di atas gambar biasa atau tarbal malam atau kontrol versi atau apa pun yang telah Anda siapkan. Pikirkan tentang strategi cadangan Anda. Maksudku, BENAR-BENAR memikirkannya.
Jangan mengandalkan daftar seperti ini untuk keamanan :) Serius! Anda akan menemukan banyak dari ini di internet, baca semuanya, teliti setiap saran, dan gunakan akal sehat dan pengalaman untuk mengambil keputusan sendiri. Pada akhirnya, pengalaman dan akal sehat adalah satu-satunya hal yang akan menyelamatkan Anda. Bukan daftar, atau alat. Bacalah, tetapi jangan hanya menyalin tanpa pemahaman.
Saya merekomendasikan Daftar Periksa Keamanan Linux , dari SAN. Saya menggunakan itu, ditambah prosedur in-house lainnya. Daftar periksa mungkin sedikit ketinggalan zaman, tetapi banyak dari poin-poin kunci tersebut terbukti benar.
Akan selalu ada izin tak terhitung untuk memeriksa, daftar periksa yang tak terhitung jumlahnya, tidak pernah berakhir penemuan bug / kerentanan baru. Keamanan Saya tidak akan berpikir ini sesuatu yang Anda nyalakan atau matikan, itu adalah sesuatu yang Anda lakukan terus-menerus.
Mengingat "kegagalan yang tak terhindarkan" dari perangkat lunak, SELinux membantu memadamkan beberapa kekhawatiran (sekali lagi tidak ada peluru perak untuk keamanan). dengan asumsi aplikasi userspace dikompromikan, kebijakan SELinux yang benar akan mencegahnya bertindak seperti biasa (yaitu jika SELinux dinonaktifkan atau permisif). Ini tentu saja akan mengharuskan Anda untuk memonitor log audit Anda dan menganalisis kebijakan yang diinstal dan memodifikasinya jika diperlukan untuk memungkinkan aplikasi berfungsi.
Tidak mengatakan kebijakan default tidak akan membantu tetapi saya pribadi ingin tahu apa yang dibolehkan.