Bunlar gerçekte OpenSSH sshd's ise, benim tahminim, bir yerde bir betiğin onları bozuk bir döngüde çalıştırdığı ve alt süreçlerinden birinin tüm bu CPU'yu tıkadığıdır.
Marki555’in önerdiği gibi, stracesize yardımcı olacaktır, ancak strace’ın strace -fçocuk süreçlerini takip etmesi için kullanmanız gerekir . Kimden man strace:
-f Trace child processes as they are created by cur-
rently traced processes as a result of the fork(2)
system call.
Strace çok fazla veri ürettiğinden, -e argümanını da kullanmak iyi bir fikir olabilir (örneğin, yalnızca açık () çağrıları göstermek için):
-e expr A qualifying expression which modifies which events
to trace or how to trace them. The format of the
expression is:
[qualifier=][!]value1[,value2]...
Sen deneyebilirsiniz başka komut ps xafveya pstree -ao sshd 's başladığı işi süreç belirleyebilmesi için kolay bir süreç ve çocuklarının ağaç görünümünü anlamak için işler. lsofAyrıca size yardımcı olabilir, bir sürecin hangi dosyaları açtığını söyleyecektir.
Ve elbette, en son OpenSSH'yi kullandığınızdan emin olun. Eski bir OpenSSH 3.4p1’de rsync + big files + ssh’ın sorunlu olacağını düşünüyorum.
Bunlar gerçekten sshd işlemleri DEĞİL ise, o zaman ikili dosyanın bir MD5 sağlama toplamı düzgün görüntülenebilir, ancak çalışan gerçek sshd programı olmayabilir. Ayrıca md5sumkomutun kendisi, belirli dosyalar (sshd gibi) için doğru sağlama toplamını bildirecek şekilde değiştirilmiş arka kapı sürüm olabilir.
/ Proc / [sshd pid] / exe dosyasına bir göz atmalı ve bunun için / usr / sbin / sshd (veya sshd'niz nerede olursa olsun) ve / proc / [sshd pid] / ortam ile bağlantı kurulduğundan emin olmalısınız. hangi ortam değişkenlerini kullandığını ve / proc / [sshd pid] / cmdline komutunu neyin başlattığını görmek için kullanın.
Bir saldırgan kötü niyetli programı "sshd" olarak yeniden adlandırmış olsa da, sshd görünmesi için onu çalıştırdı. Hatta / usr / sbin / sshd'yi / tmp / sshd konumuna taşıdıktan sonra, kötü niyetli sshd'yi / usr / sbin / sshd konumuna getirip bu tür / proc analizlerinden gizlemeyi denemek için / usd / sshd geri alındığında / usr / sbin / sshd / proc / [sshd pid] / exe sembolik bağlantısı aşağıdaki gibidir ls:
lrwxrwxrwx 1 root root 0 May 19 06:47 /proc/[sshd pid]/exe -> (deleted)/usr/sbin/sshd
Ayrıca, eğer bu sshd'ler normal süreç analizini aktif olarak engellemek için bir şeyler yapıyorlarsa , süreci “duraklatmak” kill -STOPyerine deneyebilirsiniz kill -9( kill -CONTdevam ettirmek için kullanın . Bkz. Http://en.wikipedia.org/wiki/Job_control_%28Unix%29 # Uygulama ).
Ancak, bir saldırganın kök izinleri varsa, / proc, netstat, ls, vb. Den gizlenen bir rootkit takılabilir. Gerçekten tehlikeye düşerseniz, en iyi eylem yolu sistemi çevrimdışı duruma getirmek ve bölümlerini başka bir yere monte etmektir ( temiz) sistem daha sonra adli tıp (veya adli tıp için hazırlanmış canlı Linux CD'lerden birini kullanın) yapın.
