Bir Linux sunucusunun saldırıya uğradığını gösteren hikaye işaretleri nelerdir? Bir denetim raporu planlı olarak oluşturup e-postayla gönderebilecek araçlar var mı?
Yapmazsın.
Biliyorum, biliyorum - ama gerçekten paranoyak, üzücü gerçek;) Tabii ki birçok ipucu var, ancak sistem özellikle hedeflenmişse - söylemek imkansız olabilir. Hiçbir şeyin tamamen güvenli olmadığını anlamak iyidir. Ama daha güvenli çalışmak için çalışmalıyız, bunun yerine diğer tüm cevapları göstereceğim;)
Sisteminizin güvenliği ihlal edilmişse, sistem araçlarınızın hiçbirine gerçeği ortaya koyacağından emin olamazsınız.
Geçmişte beni rahatsız eden bazı şeyler:
lsgibi standart yardımcı programlardan (bu, bozuk kök kitleriyle olabilir)
/Veya
/var/İçindeki gizli dizinler (script dosyalarının çoğu izlerini kapatamayacak kadar aptal veya tembeldir)
netstatorada olmaması gereken açık bağlantı noktalarını gösterir
bind, ancak her zaman
djbdns) kullanırsınız
Ayrıca, bir kutunun ele geçirildiğine dair güvenilir bir işaret olduğunu gördüm: Bir sistemi miras aldığınız yöneticinin titizliği (güncellemeler vb.) Hakkında kötü bir his varsa, ona yakından bakın!
Tripwire yaygın olarak kullanılan bir araçtır - açık bir şekilde önceden yüklemeniz gerekir, ancak sistem dosyaları değiştiğinde sizi uyarır. Aksi halde, bilmediğiniz yeni kullanıcı hesapları, tanımadığınız garip işlemler ve dosyalar veya görünürde hiçbir neden olmadan artan bant genişliği kullanımı gibi öğeler olağan işaretlerdir.
Zabbix gibi diğer izleme sistemleri,/etc/passwd gibi dosyalar değiştirildiğinde sizi uyaracak şekilde yapılandırılabilir.
Saldırıya uğramış sunucuları
kill - ile kontrol etmenin bir yöntemi var
Temel olarak, "kill -0 $ PID" komutunu çalıştırdığınızda, $ PID tanımlayıcısını işlemek için bir nop sinyali gönderirsiniz. İşlem çalışıyorsa, kill komutu normal olarak çıkacaktır. (FWIW, bir ölümcül öldürme sinyali geçtiğiniz için, sürece hiçbir şey olmayacak). Bir işlem çalışmıyorsa, kill komutu başarısız olur (çıkış durumu sıfırdan küçüktür).
Sunucunuz saldırıya uğradığında/bir rootkit yüklendiğinde, yaptığı ilk şeylerden biri, çekirdeğe etkilenen süreçleri işlem tablolarından vb. Gizlemesini söylemektir. süreçler. Ve bu demek oluyor ki
a) Bu kontrol kapsamlı bir kontrol değildir, çünkü iyi kodlanmış/akıllı rootkit'ler çekirdeğin bu kontrolü gereksiz kılan bir "işlem mevcut değildir" yanıtıyla yanıt vermesini sağlayacaktır. b) Her iki durumda da, saldırıya uğramış bir sunucuda "kötü" bir işlem çalışıyorsa, PID genellikle/proc altında görünmez.
, eğer şimdiye kadar buradaysanız, yöntem sistemdeki her mevcut işlemi (1 ->/proc/sys/kernel/pid_max) ve/proc içinde çalışan ancak rapor edilmeyen işlemler olup olmadığına bakın.
Bazı işlemler çalışıyor gibi görünüyorsa, ancak/proc içinde bildirilmiyorsa, muhtemelen herhangi bir şekilde baktığınız bir sorunla karşılaşırsınız.
İşte tüm bunları uygulayan bir bash betiği - https://Gist.github.com/1032229 . Bunu bir dosyaya kaydedin ve yürütün, proc'de bildirilmeyen bir işlem bulursanız, kazmaya başlamak için bir ipucunuz olmalıdır.
HTH.
Burada verilen cevapları ikinci olarak kendiminkini ekleyeceğim.
find /etc /var -mtime -2
Bu, ana sunucu dosyalarınızdan herhangi birinin son 2 gün içinde değişip değişmediğini hızlı bir şekilde gösterecektir.
Bu, bilgisayar korsanlığı algılama hakkındaki bir makaleden Sunucunuzun bilgisayar korsanlığı tarafından saldırıya uğramış olup olmadığı nasıl algılanır.
IDS kullanın
SNORT®, imza, protokol ve anomali tabanlı denetim yöntemlerinin faydalarını birleştiren, kural odaklı bir dil kullanan açık kaynaklı bir ağ saldırı önleme ve algılama sistemidir. Şimdiye kadar milyonlarca indirme ile Snort, dünya çapında en yaygın kullanılan saldırı tespit ve önleme teknolojisidir ve endüstri için fiili standart haline gelmiştir.
Snort ağ trafiğini okur ve birisinin sunucularınıza karşı tüm metasploit taramasını çalıştırdığı "kalem testi ile sür" gibi şeyler arayabilir. Bence bu tür şeyleri bilmek güzel.
Günlükleri kullanın ...
Kullanımınıza bağlı olarak, bir kullanıcı oturum açtığında veya tek bir IP'den oturum açtığında veya kök oturum açtığında veya bir kullanıcı oturum açmaya çalıştığında bunu öğrenecek şekilde ayarlayabilirsiniz. Aslında sunucu bana hergünlük iletisini hata ayıklama daha yüksek e-posta var. Evet, hatta Uyarı. Tabii ki bazılarını filtreliyorum, ama her sabah bir şey hakkında 10 e-posta aldığımda bunu düzeltmek istiyor, bu yüzden gerçekleşmeyi bırakıyor.
Yapılandırmanızı izleyin - Revizyonları takip edebilmek için tüm/etc dosyamı Subversion'da tutuyorum.
Taramaları çalıştırın. Lynis ve Rootkit Hunter gibi araçlar, uygulamalarınızdaki olası güvenlik açıklarına karşı size uyarı verebilir. Tüm çöp kutularınızın karma veya karma ağacını koruyan ve değişiklikler konusunda sizi uyarabilen programlar vardır.
Sunucunuzu izleyin - Tıpkı disk alanından bahsettiğiniz gibi - olağandışı bir şey olduğunda grafikler size bir ipucu verebilir. Cacti CPU, ağ trafiği, disk alanı, sıcaklıklar, vb. Göz kulak olmak için kullanıyorum. Bir şey görünüyorsagarip garip ve neden garip olduğunu öğrenmelisiniz.
Sadece buna eklemek istiyorum:
Bash geçmişinizi kontrol edin, boşsa ve ayarını kaldırmadıysanız veya boşaltmadıysanız, birisinin sunucunuzu tehlikeye atma olasılığı yüksektir.
Sonuncuyu kontrol et. Ya bilinmeyen I.P'leri göreceksiniz ya da çok boş görünecek.
Kabul edilen yanıtın belirttiği gibi, sistem dosyaları sıklıkla değiştirilir, değiştirilme tarihini kontrol edin. Bununla birlikte, sıklıkla değiştirilen tarihle uğraşırlar.
Genellikle rastgele bir bağlantı noktasında çalışan başka bir ssh sürümü yüklerler. Bu genellikle bazı garip yerlerde gizlidir. Normalde ssh dışında bir adla yeniden adlandırılacağını unutmayın. Bu nedenle netstat'ı kontrol edin (sıklıkla değiştirdikleri için çalışmayabilir) ve bilinmeyen bağlantı noktalarını engellemek için iptables kullanın.
Her durumda, bu önlemenin tedaviden daha iyi olduğu bir durumdur. Ödün verdiyseniz, biçimlendirmek ve yeniden başlamak en iyisidir. Kesinlikle hack'i temizlediğinizi onaylamak neredeyse imkansız.
Sunucunuzun güvenliğinin aşılmasını önlemek için aşağıdakilere dikkat edin.
Bir sunucuda olduklarında, bash geçmişinizi kontrol edecek ve o sunucudan ssh aracılığıyla bağlandığınız diğer sunucuları arayacaklarını unutmayın. Daha sonra bu sunuculara bağlanmaya çalışırlar. Kötü bir parola nedeniyle kaba zorlanırsanız, diğer sunucuya bağlanabilmeleri ve bunlardan ödün vermeleri çok olasıdır.
Dışarıda çirkin bir dünya, önleme tedaviden daha iyidir.
Biraz araştırdıktan sonra, bu da, yukarıda listelediklerimi, diğer bazı şeylerin yanı sıra yapar: http://www.chkrootkit.org/ ve http: // www.rootkit.nl/projects/rootkit_hunter.html
GuardRail'i kontrol etmelisiniz. Sunucunuzu günlük olarak tarayabilir ve neyin güzel bir görsel şekilde değiştiğini söyleyebilir. Bir ajan gerektirmez ve SSH üzerinden bağlanabilir, böylece makinenizi ve kaynaklarınızı bir ajanla gereksiz yere atmanız gerekmez.
Hepsinden iyisi, 5 sunucuya kadar ücretsizdir.
Buradan kontrol edin: