it-swarm-id.com

Memantau panggilan sistem (dengan cara yang andal dan aman)

Apakah ada metode yang dapat diandalkan untuk "memonitor" panggilan sistem di Linux?

Ada strace misalnya untuk memantau panggilan dan sinyal sistem. Apakah ada cara agar proses menghindar dari strace? Jika ya, apakah ada metode lain yang dapat diandalkan dan aman dari "pemantauan" panggilan sistem (dan, mungkin menerima sinyal), yang tidak dapat dilepaskan dari proses (dengan asumsi implementasi Linux yang tepat)?

15

Di Linux, Anda dapat dengan andal memantau pilihan panggilan sistem atau akses file dengan subsistem audit . Pastikan daemon auditd sedang berjalan, kemudian konfigurasikan dengan apa Anda ingin login auditctl . Setiap operasi yang dicatat dicatat dalam /var/log/audit/audit.log (pada konfigurasi tipikal).

Anda akan menemukan contoh sederhana penggunaan auditctldi situs ini , on Server Fault , dan on nix Stack Exchange .

strace atau program terkait yang menggunakan ptrace adalah cara yang dapat diandalkan untuk memonitor panggilan sistem, tetapi saya akan berhati-hati menggunakannya pada program jahat. Saya tidak bisa memberi tahu Anda seberapa jauh dari kepala saya, tetapi seharusnya program yang dipantau membuat panggilan ptrace yang benar untuk menghindari pemantauan.

Perhatikan bahwa program jahat dapat menghasilkan proses yang tidak diaudit dan dapat mengeksekusi kode yang tidak akan dicatat. Misalnya, bisa menggunakan mmap untuk menulis ke file tanpa konten file yang pernah muncul sebagai argumen panggilan sistem, membuat file ini dapat dieksekusi dan menelurkan proses mengeksekusinya. Proses spawned biasanya dapat mematahkan pohon proses dengan sesuatu seperti ssh localhost. Jika Anda mengaudit semua proses yang dijalankan oleh pengguna tertentu (bukan hanya satu proses dan turunannya), Anda akan dapat mencatat semuanya.

Jika ya, Apakah ada metode lain yang dapat diandalkan dan aman dari "pemantauan" panggilan sistem (dan, mungkin menerima sinyal), proses itu tidak dapat diputus (dengan asumsi implementasi Linux yang tepat)?

Untuk mengulangi dengan cara yang sedikit berbeda apa D.W. telah mengatakan, ptrace adalah panggilan sistem yang strace, gdb dan sejenisnya dibuat untuk memantau tindakan suatu proses. Ada dua masalah dengan pendekatan ini:

  1. Seperti yang mungkin Anda ketahui, mengaitkan panggilan sistem adalah teknik favorit penulis rootkit. Sangat mungkin untuk mengganti ptrace, memberikan Anda output dari proses lain atau penyimpangan lainnya.
  2. Proses tidak selalu ditulis untuk menyerahkan dengan sukarela kepada para penentang. Anda mungkin ingin membaca set tantangan ini (win32 fokus - lihat entri pertama dan terus membaca untuk membuatnya sulit) dari perusahaan appsec (saya tidak memiliki tautan dengan mereka). Sementara fokus pada mekanisme IsDebuggerPresent(), serupa solusi ada untuk ptrace . Jika Anda ingin melihat ini di alam liar dan memiliki skype yang diinstal pada kotak Linux, coba debugging itu.

    Mengulangi teknik-teknik tersebut di sini, ada dua mekanisme anti-ptrace yang jelas:

    if (ptrace(PTRACE_TRACEME, 0, 0, 0) < 0) {
        printf("being ptraced\n");
        exit(1);
    }
    

    Metode ini bergantung pada fakta bahwa suatu proses tidak dapat dilacak dua kali. Jika Anda tidak dapat melacak diri sendiri, Anda sedang ditata.

    struct timespec spec;
    
    signal(SIGALRM, SIG_IGN);
    alarm(1);
    spec.tv_sec = 2;
    spec.tv_nsec = 0;
    if (nanosleep(&spec, NULL) < 0) {
        /* EINTR */
        printf("being ptraced\n");
        exit(1);
    }
    

    Untuk menjelaskan yang ini, lihat nanosleep() dan baca artikel aslinya. Secara sederhana, nanosleep() adalah panggilan sistem yang tidak dapat dimulai kembali dan akan kembali lebih awal ketika sinyal ditangani oleh proses. Proses khusus ini akan, ketika tidak di-debug, tidak akan menangani sinyal khusus itu dan tidak akan dibangunkan. Namun, proses ptraced akan menanganinya, menyebabkan nanosleep untuk kembali lebih awal. Contoh lain di mana ini terjadi adalah select() system call.

Pada akhirnya, Anda dapat mengurangi efek 1 dengan memastikan integritas sistem Anda sebelum memulai dan menerapkan langkah-langkah keamanan yang memadai dan kernel yang dikonfigurasi dengan tepat.

Apa yang dapat Anda lakukan dengan andal tentang 2? Tidak banyak tanpa memodifikasi kode biner asli, karena setiap teknik untuk debugging akan memperkenalkan inkonsistensi yang dapat diamati atau masalah implementasi di suatu tempat.

tl; dr ptrace akan membantu Anda jika proses target tidak ditulis dengan mempertimbangkan para debugger.

10
user2213

Linux Audit Framework mendukung pemantauan syscall - saya yakin inilah yang Anda cari.

5
john

Iya. strace adalah cara yang masuk akal untuk memonitor panggilan sistem dan argumennya, selama proses yang dipantau tidak berbahaya. Jika proses yang dipantau berbahaya dan ditulis untuk menghindari strace, saya berharap itu bisa dilakukan. strace tidak ditulis sebagai alat keamanan, dan saya dapat berhipotesis beberapa cara bahwa proses itu mungkin mengalahkannya. Lihat, mis., Robert Watson, Memanfaatkan Kerentanan Konkurensi dalam Pembungkus Panggilan Sistem atau Tal Garfinkel, Perangkap dan Perangkap: Masalah Praktis dalam Alat Keamanan Berbasis Interposisi Berdasarkan Panggilan Sistem .

Jika Anda khawatir tentang kode berbahaya, Anda akan ingin menggunakan kotak pasir yang dirancang untuk keamanan, bukan alat seperti strace yang tidak dirancang untuk keamanan. Pendekatan umum untuk membangun kotak pasir seperti itu adalah menggunakan interposisi panggilan sistem baik untuk memuat proses yang dipantau, dan untuk memantau tindakannya. Salah satu metode portabel adalah dengan menggunakan ptrace, meskipun ini dapat memperkenalkan overhead kinerja non-sepele karena memaksa saklar konteks pada setiap panggilan sistem. Di Solaris, Anda dapat menggunakan/proc;/proc memungkinkan Anda menentukan subset panggilan sistem yang Anda minati, yang memungkinkan Anda mencapai kinerja yang lebih baik dengan biaya kompatibilitas.

Lihatlah Plash, Systrace, dan Subterfugue, untuk melihat beberapa sistem kerja yang menggunakan metode-metode semacam ini. Lihat juga kotak pasir Chrome, yang menggunakan berbagai mekanisme (termasuk seccomp di Linux).

4
D.W.

Bagaimana dengan memonitor panggilan sistem di sisi kernel menggunakan instance gdb eksternal.

Ini dapat dilakukan dengan menyiapkan mesin virtual yang dikonfigurasi untuk menjalankan kode kepentingan. Kemudian QEMU dan KVM (sepengetahuan saya) harus dikonfigurasikan untuk membuka port untuk debugging gdb kernel. (Lihat panduan blow.)

Jika ini VM dimulai gdb bisa dilampirkan ke kernelnya saat boot.

Langkah selanjutnya adalah mengatur properti gdb dan breakpoint untuk dijalankan pada setiap execve (dan permaisuri) yang menetapkan kode kepentingan sebagai program baru. Lalu biarkan gdb berjalan sampai menyentuh breakpoint ini. Pada titik ini selama pelaksanaan program, pid dari proses yang menjalankan kode kepentingan dapat diekstraksi dan breakpoint dapat diatur dalam gdb yang dipukul (dalam kode kernel) pada panggilan sistem apa pun dari proses ini (termasuk garpu dan eksekusi panggilan yang mungkin menyebabkan proses tambahan untuk mengamati).

Secara teori ini harus menjadi solusi yang baik yang sulit untuk doge.

Satu masalah adalah bahwa segala sesuatu di sistem tamu menjadi sangat lambat, dan Anda mungkin mendapatkan sejumlah besar panggilan yang tidak diinginkan sebagai bycatch (Anda harus memfilter menggunakan gdb ...). Gdb tambahan mungkin harus diperluas menggunakan python untuk mendapatkan breakpoint bersyarat bekerja dengan kondisi yang diperlukan (terutama untuk deteksi proses anak otomatis).

Memandu cara menghubungkan gdb ke tamu: Whamcloud Wiki , ReadHat Helpdesk , Stackoverflow

(Saya tidak mencoba panduan ini. Saya menggunakan gdb beberapa tahun yang lalu untuk men-debug beberapa detail kernel untuk proyek siswa. Di sana saya menggunakan kondisi sederhana pada breakpoint untuk mendeteksi panggilan fork dari proses tertentu.)

Di atas ini ada beberapa teknik lain untuk men-debug kernel .

PS: Perlu diketahui bahwa ada cara untuk melarikan diri dari mesin virtual (dan contoh lama ).

0
msebas