Süreçler ve loglar

Çalışan bir sisteme baktığında iki soru sorarsın: şu an ne çalışıyor ve az önce ne oldu? İlkini süreç araçları, ikincisini kayıtlar yanıtlar. Bu derste ps ve top ile çalışan süreçleri okumayı, journalctl ve auth.log ile geçmişi incelemeyi öğrenirsin.

Bir sunucuyu ele geçiren saldırganın iki klasik izini çözeceksin: işlemciyi sömüren gizli bir madenci süreci ve SSH'ye yapılan kaba kuvvet denemesi. İkisi de kayıtlarda ve süreç tablosunda açık iz bırakır.

Çalışan her program bir süreçtir ve çekirdek ona bir numara verir: PID. Her sürecin onu başlatan bir ana süreci vardır; o numaraya PPID denir. Böylece süreçler bir ağaç kurar.

Ağacın kökünde numarası 1 olan init süreci durur ve bugünkü dağıtımlarda bu süreç systemd'dir. Web sunucusunun başlattığı bir kabuk, ağaçta web sunucusunun altında görünür. İncelemede bu ilişki çok şey anlatır, çünkü bir web sunucusu normal işinde kabuk açmaz; açtıysa, altındaki süreç ağacı olayın ipucudur.

O anı birkaç araç gösterir. ps aux bütün süreçleri tek bir listede basar; satırda kullanıcı, PID, işlemci payı, bellek payı ve komut satırı yan yana durur. ps aux | grep nginx yalnız bir servisin satırlarını getirir. pstree aynı bilgiyi girintili bir ağaç olarak çizer ve ana ile alt süreç ilişkisini gözle görürsün.

top canlı bir tablo açar, birkaç saniyede bir tazeler ve en çok işlemci kullananı üste koyar. En üstteki yük ortalaması son bir, beş ve on beş dakikanın yoğunluğunu verir. htop ise top'a benzeyen, renkli ve gezinilebilir ayrı bir araçtır.

ps çıktısındaki STAT sütunu da bir süreç hakkında çok şey söyler. R çalışan ya da çalışmaya hazır süreci, S ise bir olayı bekleyen uyuyan süreci gösterir; sistemdeki süreçlerin çoğu zaten S durumundadır. D kesintiye uğramayan uyku demektir ve genelde disk beklenirken görülür.

Z bir zombiyi, T durdurulmuş bir süreci anlatır. Satırın sonundaki artı işareti sürecin ön planda olduğunu söyler. Bir süreç uzun süre D durumunda takılı kalıyor ya da çok sayıda Z görünüyorsa, bu bir sorunun işaretidir.

$ ps aux
USER       PID %CPU %MEM COMMAND
root         1  0.0  0.1 /sbin/init
root        88  0.0  0.0 [kworker/0:1]
www-data   912  0.3  1.2 nginx: worker process
www-data  4312 98.7  0.4 /tmp/.x/kworker --pool stratum+tcp://havuz.example:3333

Son satırda üç işaret birden var. Süreç /tmp altındaki gizli bir dizinden çalışır; meşru programlar /usr/bin gibi yerlerde durur. Adı kworker'dır ve çekirdek iş parçacığını taklit eder, ama gerçek çekirdek iş parçacıkları köşeli parantez içinde görünür.

İşlemci payı yüzde 98'dir ve komut satırında bir madencilik havuzu adresi durur. Tablo bir kripto para madencisini gösterir; MITRE ATT&CK buna kaynak gaspı der ve T1496 olarak izler.

Süreci durdurmadan önce kanıtı topla, çünkü öldürdüğün süreç bellekteki izleriyle birlikte kaybolur. ps -p 4312 -o pid,ppid,user,cmd ana süreci ve tam komutu verir, ana sürecin ne olduğu da olayın hikâyesini anlatır. ls -l /proc/4312/exe çalışan dosyanın gerçek yolunu gösterir; silinmiş bir dosyadan çalışıyorsa bunu da burada görürsün.

lsof -p 4312 sürecin açık tuttuğu dosyaları ve ağ bağlantılarını listeler, böylece nereye bağlandığını öğrenirsin. Notunu aldıktan sonra süreci sonlandırırsın.

$ ls -l /proc/4312/exe
lrwxrwxrwx 1 www-data www-data 0 Eyl 19 03:40 /proc/4312/exe -> /tmp/.x/kworker
$ lsof -p 4312 | grep TCP
kworker 4312 www-data 7u IPv4 48213 0t0 TCP srv1:52244->198.51.100.9:3333 (ESTABLISHED)

Kanıt elindeyken süreci kill ile durdurursun. kill 4312 varsayılan TERM sinyalini yollar ve süreçten düzgünce kapanmasını ister.

Süreç direnirse kill -9 4312 KILL sinyalini yollar; KILL yakalanamaz ve yok sayılamaz, çekirdek süreci anında bitirir. Arada bir de HUP sinyali kullanılır: bazı servisler onu alınca yapılandırmasını yeniden okur. Doğru sinyali seçmek önemlidir, çünkü KILL sürece temizlik şansı bırakmaz; açık dosyalar yarım kalabilir ve bazı kanıtlar diske yazılmadan kaybolur.

Süreci öldürmek işi bitirmez. Saldırgan bir kalıcılık yolu kurduysa, madenci birkaç dakika sonra geri gelir. En sık kullanılan yüzeyleri kontrol et. Zamanlanmış işler cron ile kurulur; crontab -l kullanıcının işlerini, /etc/cron.d ise sistem genelindeki işleri gösterir.

systemd servisleri ve zamanlayıcıları da aynı işi görür. Kullanıcının ~/.ssh/authorized_keys dosyasına eklenen bir anahtar, saldırganın parolayı bilmeden tekrar tekrar girmesine kapı açar. Çalışan süreci kapatmadan önce bu yüzeyleri taramazsan, temizlik yarım kalır.

systemd servisleri systemctl ile yönetilir. systemctl status bir servisin çalışıp çalışmadığını ve son kayıt satırlarını gösterir. systemctl list-units --type=service bütün etkin servisleri listeler ve tanımadığın bir ad kalıcılık izi olabilir.

Saldırganlar meşru adlara benzeyen servisler kurar; bu yüzden adı tanıdık diye geçme, dosyasının nereden geldiğine de bak. MITRE ATT&CK bu teknikleri ayrı ayrı izler: cron için T1053.003, systemd servisi için T1543.002, SSH anahtarı için T1098.004.

systemd kayıtları journal adlı bir depoda toplar ve journalctl onları okur. -u tek bir servisi seçer: journalctl -u ssh. -f akışı canlı izler, -b son açılıştan bu yana olanları getirir.

-p err hata ve daha önemli düzeydeki satırları süzer. --since "1 hour ago" zaman penceresini daraltır ve bunları birleştirebilirsin: journalctl -u ssh -p err -b yalnız SSH'nin bu açılıştaki hata satırlarını verir. Servis adı dağıtıma göre değişir: Debian ve Ubuntu'da ssh, Red Hat ailesinde sshd yazarsın.

Önem düzeyini bir ölçek belirler ve -p bu ölçeği kullanır. En kritik düzey emerg sıfırdır; alert, crit ve err onu izler. Sonra warning, notice, info gelir ve en ayrıntılı düzey debug yedidir.

-p err yazdığında err ve daha kritik olan her şeyi görürsün, info ve debug gürültüsü düşer. Bir olaya ilk bakışta önce err düzeyine süzmek işe yarar: kritik satırlar birkaç tanedir ve asıl hikâye çoğu zaman oradadır. Pencereyi daralttıkça ekran okunur kalır.

Düz metin kayıtları ise /var/log altında durur. Debian ve Ubuntu'da kimlik doğrulama olayları auth.log dosyasına, Red Hat ailesinde secure dosyasına düşer; SSH girişleri, sudo kullanımı ve parola değişimleri buradadır. İki kaynak birbirini tamamlar: journal yapılandırılmış ve süzülebilir, düz metin ise basit araçlarla, grep ve awk ile taranır. Bazı yeni kurulumlarda düz metin kaydı hiç tutulmaz ve aynı olaylar yalnız journal'da durur; o zaman alışkanlığını journalctl'e taşırsın.

Kaba kuvvet (brute force) saldırısında saldırgan parolayı tutturana kadar dener. Tek bir IP'den arka arkaya Failed password satırları akar ve kullanıcı adları değişir: root, admin, oracle. Sistemde olmayan hesaplar invalid user ile görünür, bu da saldırganın hazır bir listeyle geldiğini gösterir.

En kritik satır, seriden sonra gelen Accepted satırıdır: deneme tutmuştur. Parola püskürtme (password spraying) ise daha sessizdir; tek bir parola çok sayıda hesapta denenir ve kilitleme eşiği tetiklenmez, bu yüzden kaynağa göre de sayarsın. MITRE bu tekniği T1110 olarak izler.

Bir auth.log satırını alan alan oku. Sep 19 03:14:09 srv1 sshd[2310]: Failed password for root from 203.0.113.44 port 40122 ssh2 satırında baştaki üç alan tarih ve saattir.

srv1 makinenin adı, sshd[2310] olayı yazan servis ile süreç numarasıdır. Sonra sonucu söyleyen Failed password gelir, for root denenen hesabı, from 203.0.113.44 kaynak adresi, port 40122 ise saldırganın kaynak portudur. Bu alanları tanıyınca hangi kaynağın hangi hesabı denediğini bir bakışta çıkarırsın; önceki derste kurduğun süzme zinciri de tam bu alanların üstünde çalışır.

Saldırgan içeri girince izini silmeye çalışır: auth.log dosyasını kısaltır ya da satır siler. Yerel kayıt tek kopyaysa hikâye onunla kaybolur. Bu yüzden kayıtlar bir toplayıcı ile merkezî bir sisteme, bir SIEM'e hemen akıtılır.

Merkezdeki kopya, kaynaktaki dosya silinse de durur ve saldırganın erişemediği ayrı bir yerde saklanır. Sunucu saatlerini de NTP ile eşitlersin; yoksa iki makinenin kaydı aynı zaman çizelgesine oturmaz ve olayı sıraya dizemezsin.

Tespit işin yarısıdır; kapıyı da daraltırsın. sshd_config dosyasında PasswordAuthentication no parola girişini kapatır ve anahtarı zorunlu kılar. PermitRootLogin no root'un doğrudan girişini engeller; OpenSSH'nin varsayılanı zaten prohibit-password, yani root yalnız anahtarla girer.

Güncel OpenSSH sürümleri, art arda başarısız olan ya da olmayan kullanıcıyla bağlanan kaynakları kısa bir süre reddeden bir ceza düzeneğini varsayılan açık getirir. fail2ban da kayıtta tekrar eden IP'yi geçici olarak engeller ve bu iki önlem birlikte otomatik denemelerin çoğunu daha kapıda keser.

Aynı imzayı başka bir kayıtta tanı. Bir web uygulamasının giriş kaydında tek IP adresinden dakikada üç yüz başarısız giriş görüyorsun. Denenen hesap hep aynı: yonetici. Serinin sonunda aynı IP'den tek bir başarılı giriş geliyor ve bu, denemenin tuttuğunu söyler.

Araç ve kayıt değişse de desen aynıdır: yoğun başarısızlık, ardından tek başarı. SSH kaydında bu imzayı okuyabilen biri, aynı deseni bir web giriş kaydında ya da bir veritabanı kaydında da tanır. Önemli olan hangi aracı kullandığın değil; art arda gelen başarısızlık yığınını ve onu izleyen tek başarıyı görebilmendir.