WordPress, yazılım ve IT üzerine notlar
Anasayfa » Güvenlik » Sunucum ele geçirildi mi? Belirtiler, ilk kontroller ve doğru müdahale sırası

Sunucum ele geçirildi mi? Belirtiler, ilk kontroller ve doğru müdahale sırası

İçindekiler
  1. Şüphelenmenizi gerektiren belirtiler
  2. Önce: Panik yapmayın, hemen silmeyin
  3. İlk kontroller
  4. Müdahale sırası
  5. Temizlik mi, yeniden kurulum mu?
  6. Bildirim yükümlülükleri
  7. Bir daha yaşamamak için

"Sunucu ele geçirildi" cümlesini kimse duymak istemez. Ama işaretleri erken fark etmek, hasarın boyutunu doğrudan belirler. Bu yazıda, bir Linux sunucusunda şüpheli bir durumla karşılaştığınızda nelere bakacağınızı ve hangi sırayla hareket edeceğinizi anlatıyorum.

Şüphelenmenizi gerektiren belirtiler

  • Açıklanamayan yüksek işlemci kullanımı. Özellikle kworkerds, xmrig ya da rastgele harflerden oluşan adlara sahip süreçler. Ele geçirilen sunucuların en yaygın kullanım amacı kripto para madenciliğidir.
  • Sunucudan toplu e-posta gönderimi. Posta kuyruğunda binlerce ileti, IP adresinizin kara listelere girmesi.
  • Hosting sağlayıcınızdan gelen uyarı. Sunucunuzdan başka sistemlere saldırı ya da tarama yapıldığına dair bir bildirim.
  • Tanımadığınız kullanıcılar, SSH anahtarları ya da cron görevleri.
  • Web sitesinde beklenmeyen yönlendirmeler. Özellikle yalnızca mobil cihazlardan ya da arama motorlarından gelen ziyaretçilerin başka sitelere yönlendirilmesi.
  • Değiştirilmiş sistem dosyaları ya da /tmp ve /dev/shm gibi geçici klasörlerde çalıştırılabilir dosyalar.

Önce: Panik yapmayın, hemen silmeyin

İlk refleks genellikle şüpheli dosyayı silmek ve süreci öldürmektir. Bunu yapmadan önce durun. Saldırganın nereden girdiğini anlamak için ihtiyacınız olan kanıtlar o dosyalarda, süreçlerde ve loglarda. Giriş noktasını bulmadan yapılan temizlik, saldırganın aynı kapıdan birkaç gün içinde geri gelmesiyle sonuçlanır.

Kritik bir sunucuysa ya da kişisel veri barındırıyorsa, bu noktada bir uzmandan destek almayı ciddi olarak düşünün.

İlk kontroller

Aşağıdaki komutlar yalnızca bilgi toplar, hiçbir şeyi değiştirmez. Çıktılarını bir dosyaya kaydedin.

Çalışan süreçler ve kaynak kullanımı:

ps auxf --sort=-%cpu | head -30

Şüpheli bir sürecin gerçekte hangi dosyadan çalıştığını görmek için:

ls -l /proc/SÜREÇ_NO/exe
cat /proc/SÜREÇ_NO/cmdline | tr '\0' ' '

Saldırganlar süreç adlarını meşru görünecek şekilde değiştirebilir. Ama /proc altındaki exe bağlantısı gerçek dosyayı gösterir. Dosya silinmişse yanında (deleted) yazar; bu da çok güçlü bir işarettir.

Ağ bağlantıları:

ss -tunap

Tanımadığınız bir IP adresine, özellikle alışılmadık portlara kurulmuş bağlantılara bakın.

Kullanıcılar ve erişim:

awk -F: '$3 == 0 {print $1}' /etc/passwd        # root yetkili hesaplar
cat /root/.ssh/authorized_keys
ls -la /home/*/.ssh/
last -n 30
lastb -n 30 2>/dev/null | head

UID'si 0 olan, root dışında bir hesap ciddi bir alarm işaretidir. authorized_keys dosyasında tanımadığınız bir anahtar da öyle.

Zamanlanmış görevler:

for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done
ls -la /etc/cron.* /etc/cron.d/
systemctl list-timers --all

Saldırganlar kalıcılık sağlamak için sık sık cron görevi ya da systemd servisi ekler. curl ... | sh ya da base64 ile kodlanmış uzun satırlar özellikle şüphelidir.

Son değiştirilen dosyalar:

find / -xdev -type f -mtime -7 -not -path "/proc/*" -not -path "/sys/*" 2>/dev/null | grep -vE "/var/log|/var/cache" | head -50
find /tmp /var/tmp /dev/shm -type f -executable 2>/dev/null

Paket bütünlüğü:

rpm -Va 2>/dev/null | grep -E '^..5' | head      # RHEL ailesi
debsums -c 2>/dev/null | head                    # Debian ailesi (debsums paketi gerekir)

Bu komutlar, sistem paketlerine ait dosyalardan içeriği değiştirilmiş olanları listeler. /usr/bin/ps ya da /usr/sbin/sshd gibi bir dosya bu listede görünüyorsa, sistem araçlarının kendisine güvenemezsiniz.

Web siteleri:

Ele geçirilmelerin büyük kısmı bir web uygulamasından başlar. Yükleme klasörlerinde PHP dosyası arayın:

find /home/*/public_html/wp-content/uploads -name "*.php" 2>/dev/null
grep -rlE "eval\(base64_decode|gzinflate\(base64_decode|assert\(\\\$_" /home/*/public_html 2>/dev/null | head

Web sunucusu erişim loglarında, bu dosyalara yapılan POST isteklerine bakarak saldırının ilk ne zaman başladığını bulabilirsiniz.

Müdahale sırası

  1. Kanıtları koruyun. Logları, şüpheli dosyaları ve yukarıdaki komutların çıktılarını sunucunun dışına kopyalayın. Mümkünse diskin bir anlık görüntüsünü (snapshot) alın.
  2. Yayılmayı durdurun. Sunucunun dışarıya giden trafiğini kısıtlayın ya da sağlayıcınızın panelinden ağdan ayırın. Sunucu başka sistemlere saldırıyorsa bu adım acildir.
  3. Bütün kimlik bilgilerini değiştirin. Root ve kullanıcı şifreleri, SSH anahtarları, veritabanı şifreleri, API anahtarları ve uygulamaların yapılandırma dosyalarındaki her türlü gizli bilgi. Değişikliği temiz bir bilgisayardan yapın.
  4. Giriş noktasını bulun. Güncellenmemiş bir eklenti mi, zayıf bir SSH şifresi mi, internete açık bir yönetim paneli mi? Loglar, değiştirilen dosyaların zamanları ve süreçlerin başlangıç saatleri bu soruya cevap verir.
  5. Karar verin: Temizlik mi, yeniden kurulum mu?

Temizlik mi, yeniden kurulum mu?

Saldırgan root yetkisi elde ettiyse, sistemi tamamen temizlediğinizden emin olmanın güvenilir bir yolu yoktur. Sistem araçları değiştirilmiş, çekirdeğe modül yüklenmiş ya da görmediğiniz bir yerde bir arka kapı bırakılmış olabilir. Bu durumda doğru yol:

  • Yeni, temiz bir sunucu kurmak.
  • Uygulama kodunu temiz kaynaklardan (Git deposu, resmî eklenti kaynakları) yeniden kurmak.
  • Verileri (veritabanı, kullanıcı yüklemeleri) dikkatlice inceleyerek taşımak.
  • Giriş noktasını kapattıktan sonra yayına almak.

Saldırgan yalnızca bir web sitesinin kullanıcısı seviyesinde kaldıysa, örneğin bir WordPress sitesine arka kapı yerleştirdiyse ve root yetkisine dair hiçbir işaret yoksa, site düzeyinde temizlik makul bir seçenek olabilir. Ama yine de o sitenin bütün şifreleri değiştirilmeli ve çekirdek dosyaları temiz bir kopyayla değiştirilmelidir.

Bildirim yükümlülükleri

Sunucuda müşterilere ya da çalışanlara ait kişisel veriler varsa, veri ihlali bildirim yükümlülüğünüz olabilir. Türkiye'de KVKK kapsamında Kişisel Verileri Koruma Kurulu'na bildirim için öngörülen süre kısadır. Bu yüzden olayın ilk saatlerinde hukuki destek almayı ihmal etmeyin.

Bir daha yaşamamak için

Ele geçirilen sunucuların çoğu birkaç bilinen sebepten düşer: güncellenmemiş yazılım, parola ile açık SSH, internete açık yönetim arayüzleri ve tekrar kullanılan şifreler. Bunları kapatmak, düzenli ve sunucu dışında saklanan yedekler almak ve kritik dosyalardaki değişiklikleri izlemek, bir sonraki olayın ya hiç yaşanmamasını ya da çok daha küçük kalmasını sağlar.

Tezcan Kabakçı
Hosting teknik destek uzmanı ve WordPress uzmanı. 2024'ten beri bir hosting şirketinde teknik destek bölümünde çalışıyor; WordPress, DNS ve e-posta sorunlarını her gün yakından görüyor. YouTube kanalı.
Bu yazı 30 Eylül 2026 tarihinde Güvenlik kategorisinde yayınlandı.
Yeni yazılar e-postanıza gelsin

Ayda birkaç e-posta; istediğiniz an tek tıkla ayrılabilirsiniz.

Videolu anlatımlar YouTube'da
Sunucu ve WordPress sorunlarını kısa videolarla anlattığım kanala abone olabilirsiniz. ▶ Kanala abone ol

Yorumlar

Henüz yorum yok. İlk yorumu siz yazın.

Yorum yazın

Yorumlar onaylandıktan sonra yayımlanır. Bağlantı içeren yorumlar spam olarak değerlendirilebilir.