Pengerasan Linux - server web

31

Apa daftar periksa / rutin Anda saat menyiapkan server web Linux?

Apa yang Anda rekomendasikan untuk mencapai keamanan maksimum?

Apakah ada cara yang disukai untuk melakukan perawatan berulang?

pestaa
sumber

Jawaban:

27
  • 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.

jns
sumber
+1, daftar hebat! Saya akan merekomendasikan melihat ke ITK MPM ( mpm-itk.sesse.net ) daripada suexec dan Linux VServer ( linux-vserver.org ) daripada chroots. Juga, untuk pemindaian sistem file, ada tripwire atau pembantu dan chkrootkit.
David Schmitt
Jadi, pada akhirnya, melindungi server web hampir memakan waktu seumur hidup. Tampaknya Anda tidak dapat mempersiapkan dengan cukup baik, sehingga pembaruan rutin tentang kejadian aneh jauh lebih baik daripada alat keamanan pertama yang Anda temukan di manajer paket. :) Daftar yang bagus, tetapi saya akan mengambil waktu saya. Kemungkinan besar jawaban ini akan menjadi satu-satunya. :)
pestaa
@ David: Ya, dengan menyebutkan tripwire saya semacam ajudan tersirat, saya akan menambahkan tautan ajudan untuk jaga-jaga. Saya juga akan menambahkan saran vserver. Ya, virtualisasi dan / atau paravirtualization akan lebih baik daripada chroot, yang juga mengapa saya menyebutkan penjara FreeBSD. Satu hal dengan mesin virtual adalah bahwa meskipun harus meniru userland + peralatan yang dibutuhkan untuk setiap vm akan makan banyak ruang disk tambahan, yang dapat menjadi masalah
jns
jika Anda perlu melakukan virtualisasi banyak hal, atau kekurangan uang tunai / perangkat keras. Jails + nullfs mounts dapat menghindari masalah itu. dan karena penjara tidak divirtualisasi atau ditiru tidak ada overhead sama sekali. Saya kira vserver adalah hal terbaik berikutnya di GNU / Linux.
jns
Wow! Ini benar-benar hebat .. Periksa daftar periksa yang tersedia di sans.org juga. Ini sangat membantu. sans.org/score/checklists
LalakaJ
5

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.


sumber
5
  • Saya mengatur firewall, dan hanya menyodok lubang untuk menambahkan setiap layanan secara individual
  • Untuk layanan apa pun, saya membaca dokumen bantuan aplikasi untuk file konfigurasi mereka, dan memastikan saya setidaknya membaca sekilas setiap pengaturan.
  • Saya berlangganan milis keamanan
  • Saya menjalankan rkhunter dan lynis malam pada pekerjaan cron
  • Saya memiliki semua kesalahan pada ambang tertentu yang dikirimkan kepada saya
  • Saya memiliki semua perubahan yang berkaitan dengan pencatatan (memulai kembali layanan pencatatan, dll.) Diemail ke saya
  • Saya menyimpan dll dalam subversi
Tom Ritter
sumber
4

edit ~ / .ssh / config Anda

permit_root_login no

ini membuat

ssh root@server

tidak merespons tetapi

ssh user@server
user$ su

akan berfungsi jika Anda ingin login sebagai root.

devin
sumber
1

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.

putaran
sumber