Linux'ta Şüpheli Süreç ve Kullanıcı Tespiti

Sunucuna SSH ile bağlandığında her şey normal görünebilir. Load average makul, servisler ayakta, disk dolmuyor. Ama bazen bir şeyler hissediyorsun, bir sezgi gibi. İşte o sezgiye güvenmeli ve sistemi didik didik araştırmalısın. Bu yazıda, bir Linux sistemde şüpheli süreç ve kullanıcı tespitini nasıl yapacağını, hangi araçları kullanacağını ve gerçek dünya senaryolarında nereye bakman gerektiğini anlatacağım.

Neden Şüpheli Süreç Tespiti Bu Kadar Önemli?

Bir sisteme sızan saldırgan genellikle izini gizlemeye çalışır. Rootkit kurabilir, meşru görünen isimler altında zararlı süreçler çalıştırabilir veya mevcut sistem araçlarını kötüye kullanabilir. Living off the land (LotL) denen bu teknikte saldırganlar curl, bash, python gibi araçları silah olarak kullanır. Bu yüzden “yabancı” bir süreç görmek için alışılmışın dışına çıkman gerekiyor.

Gerçek bir senaryo düşün: Bir e-ticaret şirketinin web sunucusunda CPU kullanımı gece 02:00’de aniden %90’a çıkıyor. Monitoring alarmı geliyor, bağlanıyorsun. İlk bakışta Apache çalışıyor, MySQL çalışıyor, her şey normale dönmüş gibi görünüyor. Ama o CPU spike neydi? İşte buradan başlıyoruz.

Anlık Süreç Görüntüleme ile Başla

İlk adım her zaman anlık durumu görmektir. ps komutu bu iş için temel silahın.

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

Bu komut CPU kullanımına göre sıralanmış ilk 20 süreci gösterir. --sort=-%mem ile bellek kullanımına göre de sıralayabilirsin. Çıktıda dikkat etmen gereken alanlar:

USER: Süreci hangi kullanıcı çalıştırıyor?
PID: Süreç ID’si, diğer araçlarla kullanacaksın
%CPU ve %MEM: Anormal tüketim var mı?
COMMAND: Komut ismi meşru görünüyor mu?

Bir de şu komuta bak. Tüm süreçleri tam yol bilgisiyle gösterir:

ps auxww

www parametresi uzun komut satırlarını kesmeden gösterir. Bir sürecin argümanlarında şüpheli URL, IP adresi veya base64 kodlu string görürsen alarm zili çalmaya başlasın.

/proc Dizini Senin En İyi Arkadaşın

Linux’ta her çalışan süreç /proc/[PID]/ altında kendi dizinine sahiptir. Bu dizin, bir süreç hakkında inanılmaz detay barındırır ve rootkit tarafından gizlenemeyen bilgiler içerebilir.

Diyelim ki PID 1337 numaralı süreç şüpheli görünüyor:

# Süreci başlatan tam komut satırı
cat /proc/1337/cmdline | tr '' ' '

# Sürecin çalıştığı dizin
ls -la /proc/1337/cwd

# Süreci başlatan gerçek binary
ls -la /proc/1337/exe

# Açık dosyalar ve ağ bağlantıları
ls -la /proc/1337/fd

# Ortam değişkenleri
cat /proc/1337/environ | tr '' 'n'

Burada kritik bir nokta var: Eğer /proc/1337/exe silinen bir dosyaya işaret ediyorsa, yani (deleted) yazıyorsa, bu çok ciddi bir işaret. Saldırganlar bazen binary’yi çalıştırdıktan sonra disk üzerinden silerler. Süreç RAM’de çalışmaya devam eder ama dosya sisteminde iz kalmaz.

# Silinen executable'ları bul
ls -la /proc/*/exe 2>/dev/null | grep deleted

Ağ Bağlantılarını İncele

Bir cryptominer, bir C2 beacon veya bir reverse shell mutlaka ağ bağlantısı kurar. ss ve netstat bu noktada devreye girer.

# Tüm TCP/UDP bağlantıları ve hangi süreç kullandığını göster
ss -tulpn

# Sadece ESTABLISHED bağlantılar
ss -tnp state established

# Dış dünyaya açık bağlantıları filtrele
ss -tnp | grep ESTABLISHED | grep -v '127.0.0.1'

Çıktıda görmen gereken ama görmemen gereken şey şu: Bilmediğin bir IP adresine giden bağlantı. Özellikle:

Yüksek numaralı portlar (4444, 1234, 31337 klasik reverse shell portları)
Dış ülke IP’lere giden bağlantılar
Web sunucusunun 443 dışında outbound bağlantısı

PID’yi bulduktan sonra lsof ile detaya inebilirsin:

lsof -p 1337

Bu komut sürecin hangi dosyaları, soketleri ve pipe’ları açık tuttuğunu gösterir.

Kullanıcı Aktivitesini İncele

Şüpheli süreçleri bulduktan sonra sıra hangi kullanıcının ne yaptığına bakmaya gelir. Önce sisteme giriş yapmış kullanıcılara bak:

# Şu an giriş yapmış kullanıcılar
w

# Son girişler
last -n 50

# Başarısız giriş denemeleri
lastb -n 50

# Auth log dosyasına bak
grep "Failed password" /var/log/auth.log | tail -50
grep "Accepted" /var/log/auth.log | tail -20

w komutunun çıktısında özellikle FROM sütununa dikkat et. Türkiye’deki bir şirketin sunucusuna Romanya veya Brezilya’dan giriş yapılmışsa, bu soruşturulması gereken bir durum.

Şimdi kullanıcıların geçmiş komutlarına bakalım. Bash history önemli ipuçları verebilir:

# Root kullanıcısının geçmişi
cat /root/.bash_history

# Tüm kullanıcıların bash history'sine bak
for user in $(cut -f1 -d: /etc/passwd); do
    echo "=== $user ==="
    cat /home/$user/.bash_history 2>/dev/null | tail -20
done

Geçmişte wget, curl, chmod +x, ./ gibi komutların art arda kullanımı kötü bir işaret. Özellikle geçici dizinlerden binary çalıştırmak klasik saldırgan davranışı.

Yeni veya Değiştirilmiş Dosyaları Bul

Saldırganlar sisteme bir şeyler bırakır. Bu backdoor olabilir, cron job olabilir veya değiştirilmiş sistem binary’si olabilir. Son 24-48 saatte değişen dosyaları bulmak çok işe yarar:

# Son 24 saatte değişen dosyalar (sistem dizinleri)
find /usr /bin /sbin /etc -mtime -1 -type f 2>/dev/null

# /tmp ve /var/tmp altında yürütülebilir dosyalar
find /tmp /var/tmp /dev/shm -type f -executable 2>/dev/null

# Gizli dosyalar ve dizinler
find / -name ".*" -type f -maxdepth 5 2>/dev/null | grep -v ".cache|.config|.local"

/tmp, /var/tmp ve /dev/shm dizinleri saldırganların en çok kullandığı alanlardır. Bu dizinler genellikle yazma izni herkese açık olduğundan, bir web uygulaması açığı üzerinden dosya bırakmak için idealdir.

Şüpheli bir binary bulduysan hemen çalıştırma. Önce file ve strings ile incele:

file /tmp/kworker
strings /tmp/kworker | head -50

strings komutu binary içindeki okunabilir stringleri döker. URL, IP adresi, komut veya hata mesajları görürsen ne olduğunu anlarsın.

Cron Job’ları ve Servis Dosyalarını Kontrol Et

Kalıcılık sağlamak için saldırganlar cron job’larını veya systemd servislerini kullanır. Bunları mutlaka kontrol et:

# Sistem cron dosyaları
cat /etc/crontab
ls -la /etc/cron.d/
ls -la /etc/cron.daily/
ls -la /etc/cron.hourly/

# Kullanıcı cron'ları
crontab -l -u root
for user in $(cut -f1 -d: /etc/passwd); do
    echo "=== $user crontab ==="
    crontab -l -u $user 2>/dev/null
done

Systemd servislerine de bak. Özellikle yakın zamanda oluşturulmuş olanlar:

# Tüm servisleri listele ve değiştirilme tarihine göre sırala
ls -lt /etc/systemd/system/ | head -20

# Bilinmeyen servisleri incele
systemctl list-units --type=service --state=running

Sistem servislerinde kworker, systemd-update, dbus-helper gibi meşru görünen ama aslında zararlı olan servis isimleri görebilirsin. Her bilinmeyen servisin kaynak dosyasını oku.

Yetkisiz Kullanıcılar ve Sudo Hakları

Sisteme yeni kullanıcı eklenmiş olabilir veya mevcut kullanıcıya yetkisiz sudo hakkı verilmiş olabilir:

# UID 0 olan kullanıcılar (root yetkisi)
awk -F: '($3 == 0) {print}' /etc/passwd

# Son 7 günde değişen /etc/passwd ve /etc/shadow
find /etc -name "passwd" -o -name "shadow" -mtime -7

# Sudo yetkisi olan kullanıcılar
cat /etc/sudoers
ls -la /etc/sudoers.d/

# Sistemde giriş yapabilecek kullanıcılar (shell'i /sbin/nologin olmayan)
grep -v "nologin|false" /etc/passwd

Ayrıca SSH authorized_keys dosyalarını kontrol et. Saldırganlar burada kendi public key’lerini bırakırlar:

# Tüm kullanıcıların authorized_keys dosyaları
find /home /root -name "authorized_keys" -exec echo "=== {} ===" ; -exec cat {} ;

Tanımadığın bir key varsa, kim koydu bunu? Bu sorunun cevabını mutlaka bulmalısın.

Otomatik Araçlar: rkhunter ve chkrootkit

Manuel inceleme çok değerli ama zaman alır. rkhunter ve chkrootkit bu işi otomatikleştirir:

# rkhunter kurulum ve tarama (Debian/Ubuntu)
apt-get install rkhunter -y
rkhunter --update
rkhunter --check --skip-keypress

# chkrootkit
apt-get install chkrootkit -y
chkrootkit

# Sonuçları dosyaya kaydet
rkhunter --check --skip-keypress --logfile /var/log/rkhunter-$(date +%Y%m%d).log

rkhunter çıktısında Warning veya Found gördüğünde detaya in. Her warning gerçek tehdit olmayabilir ama görmezden gelmek de olmaz.

Gerçek Dünya Senaryosu: Cryptominer Tespiti

Şimdi başta bahsettiğim senaryoya geri dönelim. CPU spike’ı araştırıyoruz:

# CPU tüketen sürece bak
top -bn1 | head -20

# Ağ bağlantılarını kontrol et
ss -tnp | grep ESTABLISHED

Çıktıda şunu gördüğümüzü varsayalım: python3 prosesi %85 CPU kullanıyor ve Hollanda’daki bir IP’ye 3333 portunda bağlantı var. 3333 portu Monero mining pool’larının klasik portudur.

# Python3 sürecinin PID'ini bul
ps aux | grep python3

# O sürecin çalıştırdığı dosyayı bul
ls -la /proc/[PID]/exe
cat /proc/[PID]/cmdline | tr '' ' '

# Ağ bağlantısını öldürmeden önce kayıt al
ss -tnp | grep [PID] >> /root/incident-$(date +%Y%m%d).txt
cat /proc/[PID]/cmdline >> /root/incident-$(date +%Y%m%d).txt

Bu şekilde önce kanıt toplar, sonra süreci öldürürsün. Adli bilişim açısından kanıtları yok etmemek önemlidir.

Auditd ile Daha Derin Analiz

Eğer sistem üzerinde auditd kuruluysa, çok daha detaylı geçmiş analizi yapabilirsin:

# Auditd kurulu mu?
systemctl status auditd

# Belirli bir kullanıcının komutları
ausearch -ua 1000 --start today

# Belirli bir dosyaya yapılan erişimler
ausearch -f /etc/passwd --start yesterday

# Yeni process oluşturma olayları
ausearch -m EXECVE --start today | grep -A5 "suspicious_command"

Auditd kurulu değilse bile /var/log/syslog ve /var/log/auth.log dosyaları çok değerli bilgi içerir. Bu dosyaların silinip silinmediğini, kesilip kesilmediğini de kontrol et.

Sistem Bütünlüğü Doğrulama

Son olarak, kritik sistem binary’lerinin değiştirilip değiştirilmediğini doğrula. Debian/Ubuntu sistemlerde:

# Değiştirilmiş paket dosyalarını bul
dpkg --verify 2>/dev/null | grep "??5"

# RHEL/CentOS için
rpm -Va 2>/dev/null | grep "^..5"

??5 veya ..5 gördüğünde o dosyanın MD5 hash’i değişmiş demektir. Bir sistem binary’si değişmişse (örneğin ls, ps, netstat) rootkit olduğundan şüphelenebilirsin. Bu araçlar artık güvenilir değildir ve Live CD veya başka bir temiz sistem üzerinden analiz yapman gerekir.

Bulguları Raporla ve Sonraki Adımlar

Tüm bulgularını bir dosyaya topla:

# Kapsamlı sistem snapshot'ı al
{
  echo "=== DATE ==="
  date
  echo "=== PROCESSES ==="
  ps auxww
  echo "=== NETWORK ==="
  ss -tulpn
  echo "=== LOGGED IN USERS ==="
  w
  echo "=== LAST LOGINS ==="
  last -n 30
  echo "=== CRONTABS ==="
  crontab -l -u root
  echo "=== SUID FILES ==="
  find / -perm -4000 -type f 2>/dev/null
} > /root/system-audit-$(date +%Y%m%d-%H%M).txt

Bu dosyayı dışarıya kopyala ve analiz et. Eğer aktif bir ihlal varsa, sistemi ağdan izole etmeyi düşün. Forensics için disk imajı almak da kritik önem taşır.

Sonuç

Linux sistemde şüpheli aktivite tespiti tek bir araçla veya tek bir bakışla olmaz. ps, ss, /proc dizini, log dosyaları, cron job’ları, authorized_keys, paket doğrulama, bunların hepsini birlikte değerlendirmen gerekir. Saldırganlar akıllı ve sabırlıdır, sen de en az onlar kadar sistematik olmak zorundasın.

En önemli tavsiyem: Bu kontrolleri bir şey olduğunda değil, düzenli olarak yap. Baseline oluştur, normal sisteminin neye benzediğini bil. Çünkü normalden sapmanı ancak normali bilirsen fark edebilirsin. Aylık bir cron job kur, bu kontrollerin çıktısını kaydet, ve geçen ayla karşılaştır. Anomali kendiliğinden ortaya çıkar.

Güvende kal.

Linux Sistemde Şüpheli Süreç ve Kullanıcı Tespiti