GNU/Linux >> Belajar Linux >  >> Linux

Bertahan dari audit keamanan dengan Linux perusahaan

Sebagai administrator sistem, Anda mungkin telah mengalami kegembiraan(?) karena sistem Anda diaudit oleh profesional keamanan atau manajemen risiko. Alat keamanan yang digunakan oleh auditor umumnya memindai sistem dan menghasilkan laporan untuk auditor yang menyoroti kerentanan yang ditemukan pada sistem yang dipindai, yang kemudian disajikan oleh auditor kepada tim yang mengelola sistem. Harapannya adalah bahwa tim administrasi dan manajemen akan menyelesaikan kerentanan yang dilaporkan. Namun, untuk distribusi Linux perusahaan, perbaikan yang direkomendasikan oleh auditor mungkin bukan pilihan terbaik untuk diterapkan oleh organisasi.

Mendapatkan informasi

Dimulai dengan sebuah contoh, banyak dari alat audit ini dimulai dengan pemindaian port sistem target dan menghubungkan ke port terbuka untuk mengumpulkan data tentang layanan yang ditawarkan oleh mesin. Berikut adalah contoh pemindaian port dari sistem saya sendiri, yang dihasilkan oleh nmap perintah:

[root@somebox ~]# nmap 10.200.157.174

Starting Nmap 6.40 ( http://nmap.org ) at 2020-01-29 13:40 CET
Nmap scan report for 10.200.157.174
Host is up (0.000010s latency).
Not shown: 997 closed ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
111/tcp open rpcbind

Nmap done: 1 IP address (1 host up) scanned in 0.41 seconds

Dari output ini, Anda dapat melihat bahwa port 22, 80, dan 111 tersedia untuk layanan yang terhubung ke sistem ini. Alat audit keamanan mungkin kemudian terhubung ke masing-masing port ini untuk menentukan apa yang berjalan di port tersebut, atau mungkin menggunakan utilitas pembuatan profil untuk mengumpulkan dan menganalisis data ini. Saya akan menggunakan telnet perintah untuk terhubung ke port 80 mesin ini untuk menentukan apa yang berjalan di sana:

[root@somebox ~]# telnet 10.200.157.174 80
Trying 10.200.157.174...
Connected to 10.200.157.174.
Escape character is '^]'.
help
HTTP/1.1 400 Bad Request
Date: Wed, 29 Jan 2020 12:46:39 GMT
Server: Apache/2.4.6 (Red Hat Enterprise Linux)
Content-Length: 226
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
</p>
</body></html>
Connection closed by foreign host.

Setelah koneksi dibuat, saya harus membuat permintaan layanan. Dalam hal ini, saya mengetikkan kata "bantuan" yang, tergantung pada layanannya, mungkin berupa perintah. Untuk layanan yang berjalan pada port 80 sistem ini, bantuan bukanlah perintah yang dipahami. Akibatnya, terjadi kesalahan. Di header, Anda dapat melihat sedikit informasi bagus tentang sistem dan layanan. Secara khusus, layanan pada port ini adalah Apache versi 2.4.6.

Benar saja, jika saya memverifikasi informasi ini dengan melihat yum list , Apache versi 2.4.6 adalah versi yang diinstal dan dijalankan pada mesin:

[root@somebox ~]# yum list httpd
… output truncated…
Installed Packages
httpd.x86_64 2.4.6-89.el7_6.1      @rhel-x86_64-workstation-7.6

Menangani laporan auditor

Di sinilah hal-hal mulai menarik. Dalam pengalaman saya, apa yang terjadi adalah laporan audit mendarat di meja dan mengatakan sesuatu seperti:

Terdeteksi Apache versi lama (2.4.6) yang memiliki beberapa kerentanan yang telah ditutup di versi Apache yang lebih baru.

Rekomendasi:Instal Apache versi terbaru, 2.4.41, yang terbaru.

Pada titik ini, sebagai penerapan Linux perusahaan, Anda harus berhenti. Pahami bahwa laporan auditor menyoroti bahwa, menurut informasi pemindaian sistem, sistem ini mungkin memiliki kerentanan terbuka. Laporan auditor benar bahwa menginstal versi Apache terbaru dari apache.org akan menyelesaikan masalah itu. Namun, sebagai sistem Linux perusahaan, potensi kerentanan ini kemungkinan sudah ditutup dalam versi Apache yang saat ini diterapkan pada sistem.

Perhatikan bahwa versi pada sistem adalah 2.4.6-89.el7_6.1, dengan 2.4.6 adalah nomor versi sebenarnya, dan nomor versi tambahan untuk paket ini adalah 89.el7_6.1. Distribusi Enterprise Linux sering kali mengambil perbaikan untuk masalah dari rilis yang lebih baru dan mem-backport perbaikan tersebut ke basis kode yang lebih lama, kemudian mengkompilasi versi terbaru dari paket perangkat lunak yang lebih lama ini. Untuk Red Hat Enterprise Linux, sistem operasi pada sistem contoh saya, para insinyur yang mengelola paket Apache melacak perubahan yang diterapkan ini melalui nomor versi tambahan ini pada paket rpm.

Beberapa auditor sudah mengetahui hal ini, dan beberapa alat juga memperhitungkan jenis manajemen perangkat lunak ini. Namun, terkadang Anda akan bekerja dengan seseorang yang menggunakan alat pemindaian yang kurang canggih. Bukan hanya itu, orang ini mungkin juga tidak menyadari bahwa versi Apache yang lebih lama pada sistem ini adalah benar versi yang telah diinstal pada mesin ini, dan bahwa kerentanan keamanan yang akan menjadi perhatian orang-orang keamanan atau manajemen risiko sudah ditutup. Dan sebagai administrator sistem, seringkali Anda harus menjelaskan mengapa organisasi Anda tidak harus menginstal versi terbaru dari paket ini, bertentangan dengan rekomendasi auditor.

Dalam pengalaman saya, salah satu cara terbaik untuk mengilustrasikan hal ini adalah dengan melihat data tambahan yang disertakan dengan paket perangkat lunak versi Linux perusahaan Anda. Banyak distribusi Linux perusahaan akan menggunakan fitur seperti log perubahan RPM untuk menyorot data ini. Berikut adalah informasi dari sistem contoh saya:

[root@somebox ~]# rpm -q httpd --changelog
* Tue Jun 25 2019 Lubos Uhliarik <> - 2.4.6-89.1
- Resolves: #1719722 - CVE-2018-1312 httpd: Weak Digest auth
nonce generation in mod_auth_digest

… output truncated …

Menurut pemberitahuan CVE yang ditautkan di atas, kerentanan ini tidak diperbaiki di Apache hingga setelah 2.4.29. Namun, Anda dapat melihat dalam output log perubahan paket ini bahwa perbaikan untuk CVE-2018-1312 telah di-backport dan diterapkan ke basis kode yang saat ini diinstal, yang didasarkan pada Apache 2.4.6. Fakta ini berarti bahwa sistem contoh saya tidak rentan untuk eksploitasi ini, meskipun merupakan versi lama dari perangkat lunak Apache.

Mengapa semua ini penting? Kemungkinan, jika Anda menggunakan distribusi Linux perusahaan, Anda melakukannya karena Anda ingin meminimalkan perubahan, potensi konflik, dan masalah ketidakcocokan perangkat lunak lainnya. Memutakhirkan Apache, seperti yang ditunjukkan oleh rekomendasi audit, akan bertentangan dengan tujuan menjaga perubahan seminimal mungkin. Jika Anda adalah pelanggan yang didukung secara komersial, vendor Anda mungkin tidak akan lagi mendukung masalah terkait Apache pada mesin ini jika Anda pindah ke versi yang tidak disertakan dengan distribusinya.

Menutup

Untuk bertahan dari laporan audit, seperti contoh di atas, Anda harus bekerja dengan auditor untuk memastikan mereka memahami bagaimana paket Linux perusahaan dipertahankan (bahwa versi yang ditampilkan di port mungkin tidak sama dengan versi yang diinstal pada sistem) , dan bahwa pembuat paket Linux perusahaan umumnya memelihara versi yang lebih lama dari paket-paket ini untuk memperhitungkan kerentanan yang mungkin ditemukan oleh auditor, profesional keamanan komputer, atau rekan manajemen risiko. Menggunakan data seperti informasi changelog dapat membantu mendemonstrasikan konsep backporting dan manajemen paket Linux perusahaan ini.

Ingin mencoba Red Hat Enterprise Linux? Unduh sekarang secara gratis.


Linux
  1. Memahami panggilan sistem di Linux dengan strace

  2. Menjadwalkan tugas sistem dengan Cron di Linux

  3. Pemantauan keamanan di Linux dengan Tripwire

  1. Pantau sistem Linux Anda di terminal Anda dengan procps-ng

  2. Pindai keamanan Linux Anda dengan Lynis

  3. Menyeimbangkan keamanan Linux dengan kegunaan

  1. Perintah Shutdown Linux (dengan Contoh)

  2. Keamanan Linux:Lindungi sistem Anda dengan fail2ban

  3. Cara memeriksa versi Kernel di Linux