Sunucuda Yüksek CPU Kullanımı: Cryptominer Tespiti ve Temizliği

Sunucunuz durup dururken yavaşladıysa, fan sesleri sürekli yüksekse ya da sağlayıcı panelinde CPU grafiği günlerdir %100'e yapışık duruyorsa, ilk kontrol etmeniz gereken ihtimallerden biri cryptominer bulaşmasıdır. Ele geçirilen sunucularda saldırganların en yaygın motivasyonu artık veri çalmak değil, işlemci gücünüzü kripto para madenciliğinde kullanmaktır: sessizce çalışır, sizi doğrudan hedeflemez, ama kaynaklarınızı tüketir ve arkasında açık bir kapı bırakır.

Bu yazıda belirtileri, tespit için kullanacağınız komutları, saldırganların kalıcılık yöntemlerini ve — en kritik kısım — neden sadece süreci öldürmenin işe yaramadığını anlatıyoruz. Müdahale ettiğimiz gerçek bir cryptominer vakasının adım adım dökümünü vaka çalışmalarımızda bulabilirsiniz.

Belirtiler: Neye Bakmalısınız?

Cryptominer bulaşmasının tipik işaretleri:

Süreklilik gösteren yüksek CPU: Trafik artışıyla açıklanamayan, gece gündüz devam eden %90-100 işlemci kullanımı. Madenci, boşta duran her çekirdeği kullanmak ister.
Tanımadığınız süreç adları: kdevtmpfsi, kinsing, xmrig gibi bilinen madenci adları; ya da tam tersi, [kworker], sshd, systemd gibi meşru süreçleri taklit eden sahte adlar.
Genel yavaşlama: Web sitesi yanıt sürelerinin uzaması, SSH oturumunun bile gecikmeli çalışması.
Bilinmeyen dış bağlantılar: Sunucudan madencilik havuzlarına (genelde 3333, 4444, 5555, 14444 gibi portlara) giden kalıcı TCP bağlantıları.
Fatura/kaynak uyarıları: Bulut sağlayıcıdan gelen anormal kullanım bildirimi çoğu zaman ilk sinyaldir.

Belirtilerin tek başına kesin kanıt olmadığını da ekleyelim: yüksek CPU'nun arkasında hatalı bir uygulama döngüsü, kontrolden çıkmış bir cron işi ya da gerçek trafik artışı da olabilir. Aşağıdaki tespit adımları, meşru yük ile bulaşmayı birbirinden ayırmak için tasarlandı; sonuca komut çıktılarıyla varın, tahminle değil.

Tespit: Adım Adım Komutlar

1. CPU'yu kim yiyor?

top -o %CPU

Süreçleri işlemci kullanımına göre sıralar; en üstteki satırlarda tanımadığınız, yüksek CPU tüketen bir süreç varsa şüphelisiniz odur. Daha okunaklı bir alternatif olarak htop kullanabilirsiniz.

ps aux --sort=-%cpu | head -20

En çok CPU kullanan 20 süreci, tam komut satırlarıyla listeler. Madenci süreçleri genellikle /tmp, /var/tmp veya /dev/shm gibi geçici dizinlerden çalışır; komut yolunda bu dizinleri görmek güçlü bir işarettir.

Şüpheli sürecin gerçek dosyasını bulmak için:

ls -l /proc/PID/exe

Sürecin çalıştırdığı binary'nin gerçek yolunu gösterir; (deleted) ibaresi, saldırganın diskten sildiği ama bellekte çalışmaya devam eden bir dosyaya işaret eder — bu da tipik bir gizlenme tekniğidir.

2. Dışarıya kim bağlanıyor?

sudo ss -tnp state established

Kurulu TCP bağlantılarını, hangi sürece ait olduklarıyla birlikte listeler. Tanımadığınız yabancı IP'lere, özellikle 3333/4444/14444 gibi madencilik havuzu portlarına giden kalıcı bağlantılar arayın.

sudo ss -tlnp

Dinleyen portları gösterir; saldırganın geri dönmek için açtığı bir arka kapı burada ortaya çıkabilir. 22/80/443 dışında, sizin kurmadığınız bir dinleyici görüyorsanız not alın.

3. Kalıcılık kontrolleri: Saldırgan nereye yerleşti?

Madenciyi öldürmeden önce, onu yeniden başlatan mekanizmayı bulmalısınız. Bakılacak yerler:

crontab -l
sudo crontab -l -u root
ls -la /etc/cron.d /etc/cron.hourly /etc/cron.daily /var/spool/cron/crontabs

Tüm kullanıcıların ve sistemin zamanlanmış görevlerini listeler. curl ... | bash veya wget içeren, tanımadığınız her satır kırmızı alarmdır; saldırganlar madenciyi birkaç dakikada bir yeniden indirip başlatan cron girdileri bırakır.

systemctl list-units --type=service --state=running
ls -la /etc/systemd/system/

Çalışan servisleri ve özel servis tanımlarını gösterir. Meşru görünümlü ama sizin oluşturmadığınız (system-update.service, network-check.service gibi masum adlı) birimler klasik kalıcılık noktasıdır. Şüpheli birimin içeriğine systemctl cat AD.service ile bakın.

cat ~/.ssh/authorized_keys /root/.ssh/authorized_keys

Yetkili SSH anahtarlarını listeler; saldırganın eklediği bir anahtar, tüm temizliğe rağmen sunucuya geri dönmesini sağlar. Size ait olmayan her satır silinmelidir.

Ek kontrol noktaları: /etc/rc.local, kullanıcıların .bashrc/.profile dosyaları, ld.so.preload (cat /etc/ld.so.preload — normalde boş ya da hiç olmamalıdır; doluysa süreç gizleyen bir rootkit ihtimali ciddidir) ve tanımadığınız yeni sistem kullanıcıları (getent passwd çıktısında shell'i olan hesaplar).

4. Dosya sistemi izleri

Süreç ve ağ katmanından sonra diske bakın. Saldırının zaman çizelgesini çıkarmak için son günlerde değişen dosyaları listeleyin:

sudo find /etc /usr/local /var/spool/cron -mtime -7 -type f

Komut, kritik dizinlerde son 7 günde değiştirilmiş dosyaları döker; siz bir değişiklik yapmadıysanız buradaki her kayıt incelenmeyi hak eder. Geçici dizinlerdeki çalıştırılabilir dosyalar da klasik saklanma noktasıdır:

sudo find /tmp /var/tmp /dev/shm -type f -executable -ls

Bu üç dizinde normalde çalıştırılabilir dosya bulunmaz; çıktıda görünen her binary büyük olasılıkla saldırıya aittir. Son olarak giriş loglarına bakın:

last -20
sudo lastb | head -20

İlk komut son başarılı oturumları, ikincisi başarısız denemeleri gösterir. Tanımadığınız bir IP'den başarılı giriş görüyorsanız, giriş yolunun SSH olduğunu ve kimlik bilgilerinin ele geçtiğini varsayarak ilerlemelisiniz. Web uygulaması üzerinden girilen vakalarda ise iz, erişim loglarındaki şüpheli POST isteklerinde ve upload dizinlerinde saklıdır.

Neden Sadece "kill" Yetmez?

En sık gördüğümüz hata şudur: yönetici top'ta madenciyi görür, kill -9 ile öldürür, CPU düşer, sorun çözüldü sanılır. Birkaç dakika veya birkaç saat sonra süreç geri gelir. Çünkü:

Kalıcılık mekanizması yerinde durur. Cron görevi ya da systemd birimi, madenciyi yeniden indirip başlatır. Süreç semptomdur; cron/systemd girdisi hastalıktır.
Gözcü süreçler birbirini diriltir. Gelişmiş varyantlar iki süreç çalıştırır; birini öldürdüğünüzde diğeri onu yeniden başlatır.
Giriş kapısı hâlâ açıktır. Saldırgan içeri zayıf bir SSH parolasından, güncellenmemiş bir uygulamadan ya da internete açık bırakılmış bir uygulama portundan girdi. O kapı kapanmadıkça temizlik geçicidir; aynı botnet sunucuyu saatler içinde yeniden bulur.
Bıraktıkları tek dosya olmayabilir. SSH anahtarı, yeni kullanıcı, değiştirilmiş sistem binary'si veya rootkit; bunların herhangi biri kaldıysa sunucu hâlâ saldırganındır.

Bu yüzden doğru sıralama: önce kalıcılık noktalarını ve giriş yolunu tespit et, sonra hepsini birden temizle.

Temizlik: Doğru Sıra

Müdahalelerimizde izlediğimiz akışın özeti:

Kanıt toplayın: Silmeye başlamadan önce şüpheli süreçlerin, cron girdilerinin, servis dosyalarının ve bağlantıların çıktısını kaydedin; giriş yolunu bulmak için bunlara ihtiyacınız olacak.
Kalıcılığı sökün: Zararlı cron girdilerini silin, sahte systemd birimlerini systemctl disable --now ile durdurup dosyalarını kaldırın, yabancı SSH anahtarlarını ve kullanıcıları temizleyin.
Süreçleri sonlandırın: Kalıcılık söküldükten sonra madenci ve gözcü süreçlerini öldürün, /tmp, /var/tmp, /dev/shm altındaki zararlı dosyaları silin.
Giriş yolunu kapatın: Loglardan ilk girişin nereden olduğunu bulun; zayıf parolayı anahtarla değiştirin, açık portu kapatın, açıklı uygulamayı güncelleyin. Bu adım atlanırsa diğerlerinin ömrü saatlerle ölçülür.
Kimlik bilgilerini yenileyin: Sunucudaki tüm parolalar, API anahtarları ve veritabanı kimlik bilgileri ele geçirilmiş kabul edilip döndürülmelidir.
Yeniden kurulumu ciddi düşünün: ld.so.preload doluysa, sistem binary'leri değişmişse ya da girişin kapsamından emin olamıyorsanız, temiz kurulum + yedekten veri dönüşü en güvenilir yoldur. Ele geçirilmiş bir sistemin "yeterince temizlendiğini" kanıtlamak, yeniden kurmaktan çoğu zaman daha pahalıdır.

Müdahale ettiğimiz vakalarda en yaygın giriş yolları, parola ile açık bırakılan SSH ve internete doğrudan açılmış uygulama portlarıdır (örneğin reverse proxy arkasında olması gereken bir Next.js/Node sürecinin 0.0.0.0'da dinlemesi). Bu iki kapının nasıl kapatılacağını Ubuntu VPS güvenliği rehberimizde adım adım anlattık. Böyle bir vakada süreci uçtan uca nasıl yürüttüğümüzü görmek isterseniz cryptominer temizliği vaka çalışmamızı okuyabilirsiniz.

Tekrarını Önlemek

Temizlik sonrasında asgari koruma seti:

SSH yalnızca anahtarla; root ve parola girişi kapalı, fail2ban aktif
UFW'de yalnızca gerçekten sunulan portlar açık; uygulamalar localhost'ta, önlerinde reverse proxy
Otomatik güvenlik güncellemeleri (unattended-upgrades) etkin
CPU/RAM ve dış bağlantı izlemesi: anormal kullanım saatler değil dakikalar içinde alarm üretmeli
Sunucu dışında tutulan, geri dönüş testi yapılmış yedekler

Bu düzeni kurmak ve sürekli izlemek için bakım ve izleme hizmetimizden, tek seferlik derinlemesine yapılandırma için Linux sunucu sıkılaştırma hizmetimizden yararlanabilirsiniz. Bulaşma sadece madencilikle sınırlı değilse — site içeriği değiştiyse, verileriniz sızdıysa — sitem hacklendi, ne yapmalıyım yazımızdaki genel müdahale adımlarını izleyin.

Sık Sorulan Sorular

CPU %100 ama şüpheli süreç göremiyorum, bu ne anlama gelir?

İki ihtimal öne çıkar: ya yük meşrudur (trafik artışı, hatalı döngüye giren bir uygulama, tıkanan cron işi) ya da süreç bir rootkit tarafından gizlenmektedir. cat /etc/ld.so.preload çıktısının dolu olması ve top toplamlarının süreç listesiyle tutarsızlığı gizlenme işaretidir. Bu durumda temizliğe değil, disk imajı üzerinden incelemeye ve büyük olasılıkla yeniden kuruluma yönelmek gerekir.

Madenci sürecini öldürdüm, CPU normale döndü. Sorun çözüldü mü?

Büyük olasılıkla hayır. Kalıcılık mekanizması (cron, systemd birimi, SSH anahtarı) duruyorsa süreç geri gelir; giriş yolu açıksa aynı botnet sunucuyu yeniden bulur. Süreci öldürmek semptomu susturur; kalıcılık noktaları sökülmeden ve giriş kapısı kapanmadan temizlik tamamlanmış sayılmaz.

Cryptominer verilerimi de çalmış mıdır?

Madencilerin birincil amacı işlemci gücüdür; ancak sunucuya girebilen bir saldırgan, dosyalarınıza ve veritabanınıza da erişebilmiştir. Bu yüzden bulaşma sonrası tüm parola ve API anahtarlarının döndürülmesini, veritabanında yetkisiz erişim izlerinin kontrol edilmesini standart prosedür olarak uyguluyoruz.

Temizliği kendim mi yapmalıyım, profesyonel destek mi almalıyım?

Kalıcılık noktalarını okuyabiliyor ve giriş yolunu loglardan çıkarabiliyorsanız bu yazıdaki sırayla ilerleyebilirsiniz. Üretimde çalışan, müşteri verisi barındıran ya da tekrar tekrar bulaşan bir sunucuda ise eksik bırakılan tek bir arka kapı tüm emeği boşa çıkarır; bu durumlarda acil müdahale hattımızdan destek almanızı öneririz.

Sunucunuzda şu anda açıklayamadığınız bir CPU yükü varsa beklemeyin: WhatsApp hattımız 7/24 açık, acil müdahale ekibimiz aynı gün bağlanıp teşhis koyar. Henüz bir belirti yoksa bile ücretsiz sunucu güvenlik kontrolü ile saldırganlardan önce açıklarınızı görün.