it-swarm-tr.com

Sistem çağrılarını izleme (güvenilir ve güvenli bir şekilde)

Linux altında sistem çağrılarını güvenilir bir şekilde "izlemek" için bir yöntem var mı?

Örneğin sistem çağrılarını ve sinyallerini izlemek için strace vardır. Bir işlemin strace öğesinden çıkmasının bir yolu var mı? Evet ise, sistem çağrılarını "izlemek" (ve belki de sinyal almak) için başka bir güvenilir ve güvenli yöntem var mıdır, bir süreçten kaçamaz (uygun bir Linux uygulaması varsayarak)?

15

Linux'ta, denetim alt sistemi ile bir dizi sistem çağrısını veya dosya erişimini güvenilir bir şekilde izleyebilirsiniz. auditd arka plan programının çalıştığından emin olun, ardından neyi kaydetmek istediğinizi auditctl ile yapılandırın. Kaydedilen her işlem /var/log/audit/audit.log (tipik yapılandırmalarda).

auditctl use bu sitede , on Sunucu Hatası ve on nix Stack Exchange için basit örnekler bulacaksınız.

strace veya ptrace kullanan ilişkili programlar sistem çağrılarını izlemenin güvenilir yoludur, ancak kötü amaçlı bir programda kullanmaktan kaçınırım. Size başımın üstünden nasıl geldiğini söyleyemedim, ancak izlenen bir programın izlemeden kaçmak için doğru ptrace çağrıları yapması mümkün olmalıdır.

Kötü amaçlı bir programın denetlenmeyen bir işlem oluşturabileceğini ve günlüğe kaydedilmeyen kodu yürütebileceğini unutmayın. Örneğin, dosya içeriği sistem çağrılarının argümanı olarak görünmeden bir dosyaya yazmak, bu dosyayı yürütülebilir hale getirmek ve yürütme işlemini başlatmak için mmap kullanabilir. Ortaya çıkan süreç tipik olarak süreç ağacını ssh localhost. Belirli bir kullanıcı tarafından yürütülen tüm işlemleri (yalnızca tek bir işlemin ve onun torunlarının aksine) denetlerseniz, her şeyi günlüğe kaydedebilirsiniz.

Evet ise, sistem çağrılarını "izlemek" (ve belki de sinyal almak) için başka güvenilir ve güvenli bir yöntem var mı, bu süreç kırılamaz (uygun Linux uygulaması varsayarak)?

D.W. ne biraz farklı bir şekilde tekrarlamak için ptrace, strace, gdb ve benzerlerinin süreçlerin eylemlerini izlemek için yaptığı bir sistem çağrısıdır. Bu yaklaşımla ilgili iki sorun vardır:

  1. Muhtemelen bildiğiniz gibi, sistem çağrılarını kancalamak rootkit yazarlarının favori tekniğidir. ptrace yerine koymak, size başka bir işlemin çıktısını veya böyle bir kötüye kullanım sağlamak tamamen mümkündür.
  2. İşlemler her zaman hata ayıklayıcılara isteyerek göndermek için yazılmaz. Bir appsec şirketinden (onlarla hiçbir bağlantım yok) bu meydan okuma seti (win32 odaklı - ilk girişi görün ve zorlaştırmak için okumaya devam edin) okumak isteyebilirsiniz. IsDebuggerPresent() mekanizmasına odaklanırken, benzer ptrace için çözümler mevcuttur . Bunu vahşi ortamda görmek ve bir Linux kutusuna skype yüklemek istiyorsanız hata ayıklamayı deneyin.

    Bu teknikleri burada tekrarlayan iki açık anti-ptrace mekanizması vardır:

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

    Bu yöntem, bir sürecin iki kez izlenememesine dayanır. Kendinizi tedavi edemezseniz, kendinizi hapsedersiniz.

    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);
    }
    

    Bunu açıklamak için nanosleep() 'a bakın ve orijinal makaleyi okuyun. Basit bir ifadeyle, nanosleep() yeniden başlatılamaz bir sistem çağrısıdır ve işlem tarafından bir sinyal işlendiğinde erken dönecektir. Bu özel işlem, hata ayıklanmadığı zaman, sadece o belirli sinyali işlemez ve böylece uyandırılmaz. Ancak, çıkarılan bir işlem bunu gerçekleştirerek nanosleep 'nin erken dönmesine neden olur. Bunun olduğu başka bir örnek select() sistem çağrısıdır.

Sonuç olarak, yeterli güvenlik önlemleri ve uygun şekilde yapılandırılmış bir çekirdek başlatmadan ve uygulamadan önce sisteminizin bütünlüğünü sağlayarak 1'in etkilerini azaltabilirsiniz.

2 hakkında güvenilir bir şekilde ne yapabilirsiniz? Hata ayıklama için herhangi bir teknik bir yerde gözlemlenebilir tutarsızlıklar veya uygulama sorunları getireceğinden, orijinal ikili kodu değiştirmeden çok fazla değil.

tl; dr ptrace hedef süreç hata ayıklayıcılar düşünülerek yazılmadıysa size yardımcı olacaktır.

10
user2213

Linux Denetim Çerçevesi sistemli izlemeyi destekler - aradığınız şeyin bu olduğuna inanıyorum.

5
john

Evet. strace, izlenen süreç kötü amaçlı olmadığı sürece sistem çağrılarını ve argümanlarını izlemenin makul bir yoludur. İzlenen süreç kötü amaçlıysa ve sıkıntıdan kaçınmak için yazıldıysa, bunu yapabileceğini umuyorum. strace bir güvenlik aracı olarak yazılmamıştı ve sürecin onu yenebileceği çeşitli yollar olduğunu varsayıyorum. Bkz. Örneğin Robert Watson, Sistem Çağrısı Paketleyicilerinde Eşzamanlılık Güvenlik Açılarını Kullanma veya Tal Garfinkel, Tuzaklar ve Tuzaklar: Sistem Çağrısı Müdahale Tabanlı Güvenlik Araçlarındaki Pratik Sorunlar .

Kötü amaçlı kod konusunda endişeleriniz varsa, güvenlik için tasarlanmamış strace gibi bir araç yerine güvenlik için tasarlanmış bir korumalı alan kullanmak istersiniz. Böyle bir sanal alan oluşturmaya yönelik genel yaklaşım, hem izlenen süreci içermek için sistem çağrısı interpozisyonunu kullanmak hem de eylemlerini izlemektir. Taşınabilir bir yöntem ptrace kullanmaktır, ancak bu her sistem çağrısında bir bağlam anahtarını zorladığı için önemsiz olmayan bir performans yükü getirebilir. Solaris'te/proc;/proc, kaydırma ile ilgilendiğiniz sistem çağrılarının alt kümesini belirtmenize olanak tanır, bu da uyumluluk maliyetiyle daha iyi performans elde etmenizi sağlar.

Bu tür yöntemleri kullanan bazı çalışan sistemleri görmek için Plash, Systrace ve Subterfugue'e bakın. Ayrıca, çeşitli mekanizmalar kullanan (Linux'ta seccomp dahil) Chrome'un sanal alanına bakın.

4
D.W.

Harici bir gdb örneği kullanarak çekirdeğin yan tarafında sistem çağrılarını izlemeye ne dersiniz?.

Bu, ilgili kodu çalıştırmak için yapılandırılmış bir sanal makine ayarlanarak yapılabilir. Daha sonra QEMU ve KVM (bildiklerime göre), çekirdeğin gdb hata ayıklaması için bir bağlantı noktası açmak üzere yapılandırılmalıdır. (Kılavuzlara bakınız.)

Bu VM başlatılırsa, gdb önyükleme sırasında çekirdeğine eklenebilir.

Sonraki adım, gdb özelliklerini ve kesme noktalarını, ilgili kodu yeni program olarak ayarlayan herhangi bir execve (ve consorts) üzerinde ateşlenecek şekilde ayarlamaktır. Sonra gdb'yi bu kesme noktasına ulaşana kadar çalıştırın. Programın yürütülmesi sırasında bu noktada, ilgili kodu çalıştıran işlemin pid'i çıkarılabilir ve bu işlemin herhangi bir sistem çağrısında (çatal ve yürütme dahil) vurulan (çekirdek kodunda) gdb'de kesme noktaları ayarlanabilir. gözlemlemek için ek süreçlere yol açabilecek çağrılar).

Teorik olarak, bunun yapılması zor olan iyi bir çözüm olmalıdır.

Bir sorun, konuk sistemindeki her şeyin korkunç bir şekilde yavaşlamasıdır ve bycatch olarak çok sayıda istenmeyen çağrı alabilirsiniz (gdb kullanarak filtrelemeniz gerekir ...). Ek gdb'nin, koşullu kesme noktalarının gerekli koşullarla çalışmasını sağlamak için python) kullanılarak genişletilmesi gerekebilir (özellikle otomatik alt işlem algılaması için).

Gdb'yi konuğa nasıl bağlayacağınıza dair kılavuzlar: Whamcloud Wiki , ReadHat Yardım Masası , Stackoverflow

(Bu kılavuzları denemedim. Birkaç yıl önce bir öğrenci projesi için çekirdeğin bazı ayrıntılarını ayıklamak için gdb'yi kullandım. Orada belirli bir sürecin çatal çağrılarını tespit etmek için bir kesme noktasında basit bir koşul kullandım.)

Bunların üstünde bir çekirdeği ayıklamak için başka teknikler de vardır.

Not: Sanal makineden kaçmanın yolları olduğunu unutmayın (bir eski örnek ).

0
msebas